微服务架构

￡神魔★判官ぃ 2022-04-25 07:06 289阅读 0赞

## 微服务架构 ##

** ** 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

*  一组小的服务  
    服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
 *  独立部署运行和扩展  
    每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
 *  独立开发和演化  
    技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
 *  独立团队和自治  
    团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。

### 传统开发模式 ###

所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]

**优点：**

*  ①开发简单，集中式管理
 *  ②基本不会重复开发
 *  ③功能都在本地，没有分布式的管理和调用消耗

**缺点：**

*  1、效率低：开发都在同一个项目改代码，相互等待，冲突不断
 *  2、维护难：代码功功能耦合在一起，新人不知道何从下手
 *  3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时
 *  4、稳定性差：一个微小的问题，都可能导致整个应用挂掉
 *  5、扩展性不够：无法满足高并发下的业务需求

### **基于微服务架构的设计：** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1][]

### 微服务优点 ###

*  每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
 *  微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
 *  微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
 *  微服务能使用不同的语言开发。
 *  微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
 *  一个团队的新成员能够更快投入生产。
 *  微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
 *  微服务允许你利用融合最新技术。
 *  微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
 *  微服务能够即时被要求扩展。
 *  微服务能部署中低端配置的服务器上。
 *  易于和第三方集成。
 *  每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

### 微服务架构的缺点 ###

*  微服务架构可能带来过多的操作。
 *  需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
 *  可能双倍的努力。
 *  分布式系统可能复杂难以管理。
 *  因为分布部署跟踪问题难。
 *  当服务数量增加，管理复杂性增加。

## 需要考虑的问题 ##

*  单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
 *  单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外**通信**，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
 *  单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
 *  多个相同的微服务可以做**负载均衡**，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
 *  微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以**动态的注册**到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
 *  还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

**要实际的应用微服务，需要解决一下四点问题：**

*  **1、客户端如何访问这些服务**
 *  **2、每个服务之间如何通信**
 *  **3、如此多的服务，如何实现？**
 *  **4、服务挂了，如何解决？（备份方案，应急处理机制）**

### 常见面试题： ###

*  1、什么是微服务
 *  2、微服务之间是如何通信的
 *  3、springCloud和Dubbo有什么区别
 *  4、SpringBoot和SpringCloud，请你谈谈对他们的理解
 *  5、什么是服务熔断，什么是服务降级
 *  6、微服务的优缺点，说说你在项目中开发碰到的坑
 *  7、你所知道的微服务技术栈有哪些？
 *  8、eureka和zookeeper都可以提供服务注册与发现的功能，说说区别？

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20220126/9eaa56cedc4e4272b80e2f785584ce46.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1]: /images/20220126/dacf8479a81340dba006939c6c30f632.png