正文

一、微服务定义

1.1 定义一

微服务是一种架构风格，将单体应用划分成一组小的服务，尽量符合单一职责的原则，使得服务之间相互协作，实现业务功能；

每个服务都运行在独立的进程、虚拟机、容器、服务器中，服务之间采用轻量级的通信机制（HTTP/JSON）进行协作；

每个服务围绕各自的业务能力进行构建，并且能够通过自动化机制独立地部署，相互之间无部署依赖；

每个服务可以使用不同的技术栈进行开发；

1.2 定义二

微服务是一种基于有界上下文的，松散耦合的面向服务的架构。

二、微服务利弊

2.1 优点

• 划分了业务模块，具有更强的业务边界；
• 每个微服务都是可以独立部署的，互不影响；
• 允许技术多样性；

2.2 缺点

• 带来了分布式系统的复杂性；
• 带来了最终一致性的难题；
• 带来了运维的复杂性；
• 带来了测试复杂性；

三、微服务的适用性

什么场景下适用微服务？什么阶段时适用微服务？

3.1 康威法则

设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。

这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。

3.2 生产力

微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。

微服务与单体的生产力比较：

微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。

3.3 架构演进

如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。

建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。

架构演进：

四、服务分层

微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。

服务分层：

在常见的公司微服务总体架构中，一般的架构表现就如下所示：

微服务总体架构：

有了各个层级的服务之后，中台的概念和战略就显得很自然。

中台战略：

五、服务注册发现

服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：

• 注册中心负责维护所有服务的地址信息，包括服务名称、IP地址、端口等；
• 提供服务方将自己的信息注册到注册中心上，并维持一个心跳以此来表明自己一直可用；
• 调用服务方想要调用某个服务时，询问注册中心该服务的地址，然后以负载均衡的方式发起调用；

现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。