微服务架构简介

微服务理论基础-康威法则

康威法则：“设计系统的架构受制于产生这些设计组织的沟通结构。”**即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。

康威法则提出的各定律：

• 第一定律 组织沟通方式会通过系统设计表达出来

  即组织的沟通方式决定了系统的设计方式
  

• 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情

  罗马不是一日建成的，学习解决首要问题。产品、软件、模块功能应该首先达到最小可用程度(Minimun Viable Product)

• 第三定律 线性系统和线型组织架构间有潜在的异质同态特性

  这一定律是第一定律的具体应用，具体来说想要什么的系统就搭建什么样的团队，有什么样的团队就搭建什么样的系统。你需要搭建微服务架构的系统，那就需要微服务型的组织架构。每个团队负责自己的部分，对外提供相应的接口，团队间互不干扰，实现完全的**自治**。如此就能降低系统的依赖性，减少通信成本。
  

• 第四定律 大的系统组织总是比小系统更倾向分解

  系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理，然后统一对外沟通。微服务架构更多是关于组织和团队，而不是技术。

微服务架构定义

微服务架构是一种架构风格，没有单一的定义，随着时间的推移，业界达成已经形成共识，微服务架构的特征包括：

• 一组小的服务：怎么定义这个小，专注于做好一件事情。在一个单体系统中，避免随着新功能的增加代码库日益庞大，模块之间的界限很难维护，相似的代码随处可见，通常会创建一些抽象层或者模块来保证代码的内聚性。在使用微服务架构时一个微服务同样要具有内聚性这一概念，Robert C.Martin有一个单一职责原则：把因相同原因变化的东西聚合在一起，而把不同原因而变化的东西分开。微服务中独立服务的划分程度，同样有内聚性、单一职责原则，根据业务的边界来确定某个功能代码应该放在那个微服务之中，确定该微服务专注的业务边界之内。

• 独立的进程：每个服务运行在独立的进程中，能够以进程的方式进行横向扩展。

• 轻量级通信：服务之间均通过网络调用（HTTP REST/RPC）进行通信，从而加强服务之间的隔离性，避免紧耦合。

• 基于业务能力：基于业务能力来划分服务的边界。确定对于一个服务来说，我们应该暴露什么，应该隐藏什么。一个服务的变动，应该尽量避免该服务消费者的变动。

• 独立部署：每个服务模块的开发人员可以进行完全的自治，独自开发、测试、部署。团队之间减少沟通的成本。

• 无集中式管理：每个团队可以根据各自的业务需要，可以采用不同的技术栈，不同的存储机制，能够高效的完成业务目标即可。

  总结来说：微服务架构风格就是小而自治的服务，可以采用不同技术栈，拥有独立进程，进程之间采用网络调用通信，不同团队在业务边界之内开发、测试、部署。

服务架构演进

微服务优点

1. 技术异构性：不同的服务可以采用最适合该服务的技术。

2. 弹性：系统一个服务故障，不会引起级联故障，系统的其他组件还能使用。

3. 扩展：庞大的单块服务只能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。

4. 简化部署

5. 更小粒度的服务粒度，带来的易于重用已有的功能

6. 服务更改维护代价更小

微服务缺点

1. 服务间的通信成本。

2. 分布式系统的复杂性。

3. 服务的运维管理。

4. 分布部署服务出错,问题的定位追踪。

微服务支撑组件

微服务只是一种架构手段，当我们将一个单体系统拆分成微服务架构风格时，微服务架构的带来问题该如何解决呢？比如服务进程之间的通信、服务之间错中复杂的依赖关系导致的线上问题如何排查、分布式系统带来的一致性问题等问题。因此微服务产生了一些系列的支撑组件：

1. 服务治理
2. 服务负载均衡
3. 服务网关
4. 熔断、限流、降级
5. 服务分布式链路跟踪
6. 统一配置管理

微服务组件选型

注册中心选型

负载均衡组件选型

服务网关选型

配置中心选型

熔断组件选型

服务调用链路追踪组件选型

微服务架构图

图片来源互联网：https://www.owensun.com/microservice-refercence-architecture/

参考文章

• [1] 微服务理论
• [2] 康威法则