微服务概念详解（微服务架构20讲学习手记）

微服务概念详解

本文主要是王波老师微服务架构20讲的学习心得

1.微服务与单体架构

假设有一个用户信息管理系统，包含了注册、登录、信息维护、授权四个核心功能，如上图所示，使用单体架构时，所有的功能会被放在一起，而使用微服务架构时，它们可以被拆分成四个独立的服务

2.微服务定义

讲到为服务的定义，不得不提到两个人

2.1Adrian对微服务的定义

Adrian是Netflix前架构总监，经历了Netflix从单体架构到微服务架构的演变，这里给出了他对微服务的定义，比较重要的有三个地方

1. Loosely Coupled（松散耦合，不能强依赖，如果有个团队对其他团队的依赖很强，那么就不能称之为微服务）

2. Service Oriented architecture（服务面向的架构，他认为微服务本质上还是SOA，只不过是细化的SOA，更落地）

3. Bounded Context（有界上下文，术语是局部状态，这一点比较重要。就是说服务之间有边界，每个团队维护自己的数据源，无集中式的数据管理，所以每个团队可独立维护，可独立演化）

2.2Martin Flower提出的关于微服务特点

第二个人是Martin Flower，他在2014年的一篇文章中讲到微服务应当具有的6个特点

1. 一组小的服务
   单块架构把所有的应用打包到一个单块的应用之中，微服务主张拆出来，成一个个微服务，小没定义，可以让人员容易理解即可。在划分微服务时，我们需要避免一味追求小而将微服务划分得过细，因为这样会提高系统维护成本
2. 运行在独立的进程中
   例如JAVA开发的单体架构系统，所有业务功能包含在一个WAR包里，部署在相同的容器中，业务功能之间共享进程。而微服务之间是独立的，他们可以部署在一个容器里，也可以分开部署，最重要的是它们之间不会共享进程。这样做有利于灵活的分配资源，各个服务之间也不会互相干扰。
3. 使用轻量级通信协议
   单体架构下，不同系统间的交互常常会使用重量级的协议，例如SOAP。微服务由于拆分得更细，服务间调用更加频繁，因此更倾向使用轻量级的协议，例如Http、RPC。
4. 基于业务能力构建
   划分微服务的原则不是看它有多小，而是看单一的业务能力是否被划分到一个服务中，例如前面的用户信息管理系统，我们是按业务能力划分了四个微服务，而不是按功能划分出前端服务、接入服务、逻辑服务、数据库服务
5. 独立部署
   独立部署的特性，使得微服务架构系统能够以更快的速度迭代，而这也是互联网软件非常重要的一个特性。
6. 无集中式管理
   单体服务架构由于集中管理，所以使用的技术栈往往也是相同的。微服务架构则可以根据服务特性选择不同的技术栈，例如注册服务用 MYSQL + REDIS，信息维护服务使用Oracle。无集中式管理使得微服务架构系统的选择性更多，可以根据需求选择最优的技术方案。

3.微服务的利与弊

利：

1. 模块化一直是软件设计中的一个重要原则，有了模块化，我们才可以做到高内聚、低耦合。实现模块化的方式很多，可以是一个类，也可以是一个独立的组件。微服务架构则将模块化上升到一个更高的层次，以服务的形式的实现。服务与服务之间采用远程调用的方式进行交互，这样它们之间没有干扰和冲突，边界非常清晰
2. 例如我们需要给用户信息加字段，只需要修改用户服务，其它的服务并无感知。而单体架构就要麻烦很多，即使是变更一个小功能点，也需要发布整个系统
3. 由于微服务不是集中式管理，所以不同服务的技术团队，可以基于自身技术特点或者服务的业务特性选择完全不同的技术栈。比如有的团队更熟悉Java，那么他们可以选择Java做为开发语言，另一个团队更熟悉Python，则可以用Python来开发。

弊：

1. 微服务的特点是服务众多，并且实现技术多样，这样带来的挑战就是增加了研发人员的理解和学习成本。一个单体架构系统，技术栈是统一的，而且系统架构简单，就只有单体应用的几个节点，研发人员理解起来非常容易。
2. 微服务架构是一种分布式系统架构，对于任何分布式系统而言，数据的最终一致性都是一个绕不过去的坎。要么在最终一致性上做妥协，由强一致性变为弱一致性。要么使用复杂的设计实现最终一致性，但是开发的成本也会因此提升
3. 微服务对于运维在部署、监控、扩展、管理等方面都提出了更高的挑战。例如服务增多以后，不可能还是手工一个个部署，必须要借助自动化工具批量操作。追查问题的难度也变高了，一个问题可能涉及多个服务的层层调用，如果没有一个好的链路追踪以及日志查看工具，即使是简单的问题，追查起来也会非常耗时耗力。
4. 测试复杂性
   对于单体应用，直接测试整个系统功能就可以了；微服务后，各个系统分散在各个团队，需要多个团队联调做集成测试。

总体而言：关于微服务的利与弊，其实就是把一个系统细分为多个服务后，系统可看做整体，每个微服务可看做部分。好处是容易把控每个微服务自己，各个团队负责自己的服务就好了，坏处就是对系统整体的把握上会出现一些不便，比如对系统整理的理解、对系统的测试等。

那么基于微服务的利与弊，一个企业应当何时引入微服务架构呢？

4.微服务引入

4.1企业何时引入

这是一张效率随团队规模变化的图，蓝色表示单体架构，绿色表示采用微服务架构。

项目初期,项目的用户量不大,业务也并不是很复杂,我们如果选择单体项目的话,我们的开发成本最低,开发效率最高,而选择微服务架构,我们要准备很多资源,开发成本较高,开发的效率也就很低;随着项目的更新迭代,用户群里变多,往往要在老模块上更新迭代,那如果选择单体,我们就要做一系列的改动,就类似于康威法则中描述的问题,容易产生冲突,那如果选择了微服务架构,我们就可以很好的解决这个问题,从而效率变高.

我们可以观察下这个图有一个交叉点,个人理解,可以项目初期使用单体架构,但要对项目的包结构,模块等有一定的规划,方便我们整改成微服务架构,当我们发现继续使用单体项目开发和整改成微服务的成本几乎差不多的时候,我们就要根据项目的发展以及规模考虑是否要拆分成微服务架构。

4.2怎样引入微服务

单体优先原则：不宜过早引入微服务，因为系统初期对系统的未来发展无法预知，过早引入微服务风险较高。不要在系统初期直接上微服务架构，而是在系统演变过程中逐渐引入。

比如上图，模块4成熟了之后就先把4给拆分出来当作一个微服务

5.康威法则（微服务的理论基础）

康威法则：设计系统的组织，其产生的架构设计等价于组织间的沟通结构

比较拗口，简单来讲就是：系统的架构等价于组织的架构

我们看下边这两张图

刚开始团队规模并不大，业务也不大，可以都是单体的，但随着业务规模增大，团队内有了分工，团队是分布式的，系统架构是单块的，开发，测试，部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突

这时将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。

如果系统是单体应用，那么应该是一个团队负责。

如果系统微服务化以后，比如分为服务A，B，C，那么组织架构上，也应当划分为A，B，C三个团队，每个团队可独立迭代

6.微服务的组织架构

传统的组织架构：

一个产品需要产品团队、用户体验团队、研发专家团队、测试专家团队、DBA专家团队、运维专家团队等。这样会有两个问题，一个是沟通成本较大，另一个是反馈比较慢。

对于为服务来说，这样就不太好了，因为每一个微服务都有自己专属的产品、研发、测试人员。团队成员围绕微服务进行不断的迭代开发。微服务不像项目，结束之后人员回到各自组织。微服务是可以一直存在的，因此人员也可以在微服务中长期保持合作关系，跨部门的沟通成本大大降低。

为了契合微服务小、灵、快的特点，更提倡大家使用跨职能产品组织架构。

这种组织架构的核心，是开发微服务的团队，应该负责微服务的设计、开发、测试、部署直至运行的全生命周期，形成一个完整的闭环。

7. 一个简单清晰的分层方式

怎么分层业界没有统一，这里给出的只是一种
外边就是外部设备，接到平台上，平台统称为微服务或SOA，微服务简单分为两层，第一层称为基础层，比较基础性的支撑服务，电商：购物车服务，商品，订单，原子性的服务，比较通用，向上提供业务能力，

第二层，为啥需要这一层？因为有不同的接入端，对于不同的外部介入，需要做不同的适配，聚合，裁剪的工作，比如有一个商品服务，对PC端和手机端的呈现可能不太一样，屏幕要裁剪，另外要聚合，把商品信息，购物车信息，订单信息同时呈现到PC端，涉及到好几个服务同时调用，有聚合层效率较高。

8.微服务的技术架构

上图是一个常见的6层的微服务技术架构体系。

这个体系按照请求接入，由外到内的顺序，将整体架构分为接入层、网关层、业务服务层、支撑服务层、平台服务层和基础设施层六层。

1. 最外层是接入层，通过负载均衡接入请求到内部平台，这些请求既有外部互联网请求，也有公司内部其它系统的请求。

2. 网关层是微服务架构的核心层，是业务层接收外部流量的屏障。1.对接入的流量进行反向路由。2.拦截所有的请求，通过横切的方式完成熔断、限流、安全认证等功能。3.对请求进行分类，例如内部网关、H5网关、图片网关。

3. 第三层是业务服务层，我们常说的微服务就集中在这一层，这里包含了系统核心的业务逻辑。刚才已经详细讲过。基础层提供单一简单的基础服务，例如人员、订单、支付。聚合层则是将不同的基础层聚合在一起，完成复杂的业务处理。

4. 支撑服务层提供非业务功能，以支撑业务服务层和网关层软件的正常运行。

5. 平台服务层站在系统平台的角度上，处理系统发布、资源调度整合等功能

6. 基础设施层与软件关系不大，主要是支撑系统需要的硬件资源

另外，六层体系中还有一些纵向能力：微服务开发框架、持续交付流水线、端到端的工具链、工程实践和规范。例如微服务开发框架，提供标准的开发框架规范开发过程，统一开发标准。持续交付流水线，提供从研发到测试，再到生产的持续交付能力。

9. 微服务中台战略

这是阿里巴巴提出的微服务中台战略，是马云在去欧洲参观了一个规模很小，但效率贼高的公司之后提出的。他把技术架构又分了业务前台，业务中台和技术中台。强调大中台，小前台，
强化“技术中台+业务中台”，中台肥沃，在这上面的业务生态才会更繁荣。业务应用更小更灵活，迭代能力变强，按照市场变化不断演化新应用出来

10. 容器部署技术与持续发布流水线

微服务这一概念的落地要得益于容器技术的发展，容器技术主要解决了以下问题：

1. 环境的一致性。
   Docker 彻底解决环境不一致这一问题，当我们在开发环境使用Docker 构建好应用的镜像后，可以直接在生产上使用同一个镜像，保证了线上、线下环境的一致性
2. 减少了部署的重复工作
   用Docker ，我们只需要直接打包一个环境的镜像然后运行即可，无论
3. 快速交付
   部署变得容易的同时，可以实现快速交付，为持续集成创造了条件。
4. 安全性高
   容器和操作系统隔离，彼此互不干扰，无疑提高了系统安全性。
5. 易集成
   将不同应用部署在不同容器当中，解除了精合，方便和其他应用集成。
6. 自带体系
   Docker 既是独立的，又是完整的小生态，可以被各处运行。

这里给出一个基于镜像治理和多环境的持续交付流水线，如下图所示：

首先提供代码，之后用常用的工具比如Jenkins来构建单元测试和打镜像，然后上传到镜像治理中心。若采用流水线方式会有一个规范的流程，先发布到测试环境，若在测试环境通过了之后提交到UAT环境，打一个标签，然后发布到UAT环境，通过之后以通过蓝绿或者灰度的形式发布到生产环境。

注：蓝绿发布和灰色发布

蓝绿发布：项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。

灰色发布：灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。