前言：架构的演变流程

单体架构 ==> 垂直架构 ==> 前后端分离 ==> EAI架构  ==> SOA架构 ==> 微服务 ==> 微服务2.0

1、单体架构：在软件设计时经常使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，所以典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。（大单体）

2、垂直架构：将原来的一个大项目，按照业务场景拆分为互不相干的单体架构的项目（纵向拆分）

3、前后端分离：在前后端分离的架构中，前端关注页面的样式与动态数据的解析及渲染，而后端专注于具体业务逻辑，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。（横向拆分）

4、EAI架构：将异构平台的业务系统进行集成的一种技术，主要解决各个系统各自为政，相互无法连通，形成信息孤岛的问题。EAI使用中间件作为粘合剂，来连接各个业务相关的异构系统、数据源，从而满足应用系统之间信息共享的需要。（连通相互独立的系统，解决信息孤岛）

5、SOA架构：将各个系统的不同功能单元抽象为服务，服务间彼此通过标准的接口协议连接起来，并以此完成特定功能的实现。当出现新的业务需求时，不需要从零开始实现，只需将已有的服务进行编排装配来实现新业务。（服务复用与编排）

6、微服务：微服务是SOA思想的一种提炼，它强调业务系统彻底的组件化和服务化，通过有效的拆分系统，实现敏捷开发和部署。原有的单个业务系统被拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。（SOA是对异构系统的服务化，微服务专注服务的拆分）
（1）微服务1.0时代：基于 SpringCloud 或者 dubbo 框架进行开发，仅使用服务注册与发现与服务网关等策略
（2）微服务1.5时代：使用了熔断、限流、降级等服务治理策略，并配备完整服务工具和平台

7、微服务2.0：以 ServiceMesh 为代表，将服务治理作为通用组件并下沉到平台层实现，使得应用层仅仅关注业务逻辑。将业务所有的流量都转发到 ServiceMesh 的代理服务中，由服务网格帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制。此外，ServiceMesh 还承担了微服务框架所有的功能，包括服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速等，不同的是，Service Mesh强调的是通过独立的进程代理的方式。（以代理的方式建立稳定的通信）

一、大单体架构：

对于单体架构、垂直架构、前后端分离架构，我们都可以统一归类为单体架构的范畴。在这几种架构下，随着项目的不断发展，都会使得整个系统不断变得更加庞大，最后形成一个大单体。

1、单体架构项目的好处在于：

• 项目架构简单，前期开发成本低，周期短，能够快速实现系统的从0到1，是小型项目的首选。
• 可以随时开发、调试、测试整个系统的功能，不需要额外的一些条件和准备步骤，节省大量的时间。

2、但是，单体架构也存在不利于系统长期稳定发展的诸多弊端：

（1）代码质量：

• 代码量大，逻辑复杂且腐化严重，只有少数员工能理解全部内容，代码可维护性变差
• 存在代码严重耦合的情况，即使按不同模块按照package来划分，但各模块的代码仍可以直接相互引甩，导致了系统内的对象间依赖关系混乱
• 熔断降级全靠 if-else

（2）开发效率：

• 团队协作效率变差，公共功能重复开发，且多人开发一个项目，提交代码频繁出现大量冲突。
• 开发调试过程中的编译时间长，影响开发效率

（3）系统可靠性：

• 系统耦合性高，可能牵一发而动全身。修改一处代码，可能导致一大片的功能无法正常使用，减低系统的可用性，提高bug出现的概率。
• 系统变更对部署的影响大。部署单元是整个系统，任何业务逻辑调整都需要重新打包整个系统，部署、停机、再重启，系统发布时间长，同时回滚耗时也相应增加，这种部署模式大大提升了系统风险，降低了系统的可用性。
• 系统可靠性变差，如果某个进程出现内存溢出等故障，将导致整个节点崩溃

（4）扩展性：

• 主要业务和次要业务耦合，横向扩展复杂。系统性能扩展只能通过扩展集群结点，成本高。

所以，单体架构比较适用于规模较小的系统，特别是需要快速推出原型实现，以质量换速度的场景。

二、EAI架构：

1、什么是 EAI ？

EAI 是将基于异构平台下的业务应用系统集成在一起的一种技术，是解决各个系统之间的互联、互相传输数据的一种解决方案。那为什么要出现这种解决方案？这主要是企业在发展过程中，出现了各种各样的应用系统比如ERP、PLM、财物系统、CRM等等，这些系统都是相互独立的，相互无法互通互联，形成 “信息孤岛”，企业无法实现对整体业务运作和流程管理的全面掌控。而 EAI 可以通过中间件作为粘合剂来连接企业内外各种业务相关的异构系统、应用以及数据源，从而满足企业内部应用系统之间信息共享的需要。 

2、EAI 系统的集成方式：

EAI 的集成方式可从以下的几个层面来实施：

• 用户界面集成：这个层面是一个面向用户的整合，强调将来自多个信息源的信息以一种可以定制的、个性化的界面展现给用户。
• 应用集成：以应用系统为基本集成单位，通过中间件，为两个应用系统提供业务集成。
• 数据集成：数据集成是应用集成的基础。在实施集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型。这三步完成以后，数据才可以在多个数据库系统之间进行分布和共享

注：从EAI 集成的三个层面来看，完全和SOA集成的三个层面相同

3、EAI 架构的形式：

EAI 架构一般可以分为以下两种形式：

（1）星形拓扑架构：

由处于系统中央的一个 Hub 和连接在 Hub 及应用系统的多个适配器(adapter)组成。适配器在 Hub 和应用系统之间，进行数据格式的转换与传输。适配器将应用系统的数据信息转化为 Hub 可以识别的格式并传递给 Hub。Hub 通过消息代理管理消息路由，并将这些来自应用系统的数据消息按其要求的路由规则传递给目标系统的适配器。

这种架构中的 Hub 使得系统易于管理，但是不易扩展。在需求突增时，只能通过硬件的升级才能增加系统容量，但这种升级方式的改进是有限的，不足以应付越来越多的整合需求

适配器的主要功能是做已有系统和中间层之间的数据转换；已有系统接口调用的封装，统一接口和已有系统接口的适配。

（2）总线架构：

总线架构是星型架构的变形。将星型架构中心点 Hub 的传输消息的功能提炼成一条消息传递总线，而将适配器、集成引擎绑在了应用系统所在的平台。应用程序使用适配器转换消息格式，并将消息发送到总线上。这些消息通过消息总线流动到预订的应用系统的适配器中。适配器再将消息翻译成符合其应用系统要求的格式。

4、EAI 系统存在的问题：

EAI 架构的解决方案和思想是制定统一的数据和接口定义，使 EAI 应用的开发者能够使用一种数据和接口定义来实现新的业务，由平台统一处理不同系统间的数据和接口的之间的适配，把应用系统对其他系统的接口调用以及异构数据转换的工作移到EAI集成平台中去做，应用系统简单了，系统互联的架构也从点对点优化为总线的方式（总线架构包含两个层面的含义：连接层面，数据层面）。

但带来的问题是在 EAI 平台上的接口调用和数据转换的逻辑由谁来做，由谁来维护。 从逻辑上这部分逻辑还属于应用系统的范畴，但在技术上这部分逻辑和应用系统主体已经分离。应用系统调用方通常没有在 EAI 平台上的开发能力，不愿意做这部分工作；集成提供方有 EAI 平台上的开发能力，但不了解应用系统的数据和接口调用逻辑。

三、分布式架构：

前面说过，我们可以把 EAI 架构看做是单体和分布式之间的过渡状态。这是因为在大量的EAI项目实施的基础上，架构设计关注的不仅仅是单个的项目，而是企业的所有系统。架构师们需要以超越单体架构的分布式思想和业务服务能力的角度来看待问题，这样面向服务架构即SOA就发展起来了。在讲 SOA 架构的之前，我们先了解一下什么是分布式架构。

1、分布式架构介绍：

1.1、什么是分布式架构：

​分布式，顾名思义就是将服务拆分成不同的部署单元并部署在不同的机器上，一个服务可能负责几个功能，且各分开部署的部分彼此通过各种通讯协议交互信息。通过分布式架构，可以解决前面介绍单体架构提到的 项目不断变庞大时产生的各种不利于系统长期稳定发展的问题，包括代码质量、开发效率、系统可靠性和扩展性等，但是分布式在解决单体架构中的问题的同时，也引进了其他问题，比如：

• （1）系统间耦合度变高，调用关系错综复杂，难以维护。
• （2）在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。

1.2、分布式架构的类型：

• 面向服务架构(Service Oriented Architecture，SOA)：以业务服务的角度和服务总线的方式 （一般是WebService与ESB）考虑系统架构和企业IT治理； 
• 分布式服务架构（Distributed Service Architecture，DSA)：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理；
• 微服务架构（MicroServices Architecture，MSA)：微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。 

2、SOA架构：

2.1、SOA架构介绍：

SOA，即面向服务架构，它最基本的业务功能单元是服务，将各个系统的不同功能单元抽象为服务，实现不同模块的解耦，服务间彼此通过标准的接口协议连接起来，从而实现各异构系统间的服务调用、消息交换和资源共享，并以此完成特定功能的实现。而不同服务间通信的桥梁，就是由服务总线担当的，一般是 ESB，通过 ESB 完成业务系统与其他系统的功能调用的统一接入，业务系统和公共功能作为标准服务在总线上公开，隔离服务消费者和服务提供者的技术实现细节，实现松耦合。也就是说，所有的服务调用均通过服务总线进行。当出现新的业务需求时，不需要从零开始实现， 只需将已有的服务进行编排装配来实现新业务。

接口协议是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务能够通过统一和通用的方式进行交互。

但 ESB 服务总线不保存服务信息，在运行时，它动态地会通过服务目录的查询接口，查询服务的路由信息、访问权限、优先级、版本信息等，从而决定如何进行服务调用。通过 ESB 实现服务管理和治理，对服务进行统一管理的技术平台。

在 SOA 架构中有两个最重要的事情，其一是抽象各系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。这个思想和中台思想完全一致。通过复用与编排，可以快速实现应用集成，进而适应不断变化的业务需求，快速提升竞争力。SOA 也使软件系统向“柔性化”迈进了一大步，在 SOA 中，只需要根据新的情况修改服务的执行者，而不需要修改服务的请求者。

2.2、SOA 架构的好处：

（1）从宏观的视角来看，不同于以往的孤立业务系统，SOA 强调整个企业系统生态环境是一个大的整体，各系统的业务拆解为不同粒度和层次的模块和服务，服务可以组装到更大的粒度，不同来源的服务可以编排到同一个处理流程，实现非常复杂的集成场景和更加丰富的业务功能。

（2）从研发的视角来看，系统的复用从以前代码级的粒度，扩展到业务服务的粒度；能够快速应对业务需求和集成需求的变更

（3）从管理的角度来看，SOA 从更高的层次对整个企业的系统进行统一的设计与管理，对消息处理与服务调用进行监控，优化资源配置，降低系统复杂度和综合成本，为业务流程梳理和优化提供技术支撑。在SOA体系下，应用软件被划分为具有不同功能的服务单元，并通过标准的软件接口把这些服务联系起来，以SOA架构实现的企业应用可以更灵活快速地响应企业业务变化，实现新旧软件资产的整合和复用，降低软件整体拥有成本。 

2.3、SOA的两大基石：

SOA关注于系统的服务化，那么不同系统服务间的相互通信就成为了一个重要的话题。并且随着 RPC 和 MQ 技术的发展，这两种技术逐渐成为SOA的两大基石，也是分布式技术体系里的重要基础设施。

（1）RPC技术：

两个系统间的通信往往可以通过 socket + 自定义数据报文来实现，但是这种方式比较繁琐，需要针对每个通信场景定义自己的数据格式和报文标准，甚至交互的行为、异常和错误的处理等等。有没有一种通用的技术手段呢？答案就是RPC技术。

RPC是一种通用性的系统通信手段，可以让我们像调用本地方法一样调用远程系统提供的方法。从本质上看，RPC 对于客户端的来说是一种同步的远程服务调用技术。与其相对应的，MQ恰恰是一种异步的调用技术。

（2）MQ消息队列：

所有的处理请求先作为一个消息发送到MQ，接着处理消息的消费者系统从MQ拿到消息并进行处理，这样就实现了各个系统间的解耦，同时可以把失败策略、重试等作为一个机制，对各个应用透明，直接在MQ与各调用方的应用接口层面实现即可。使用 MQ 的好处有以下几点：

• 增加系统的异步业务处理能力
• 降低系统间的耦合性。通信的双方只需要定义好消息的数据格式（消息头有什么字段，消息体是什么格式的数据），就可以各自开发和测试，最后再各自上线即可集成到一起。
• 削峰填谷，提升了系统的业务缓冲能力，如果业务量突然增大时可以先把处理请求缓冲到队列中，再根据业务消费处理能力逐个消息处理，保障了系统不会因为突然爆发的大量请求而过载瘫痪，影响系统的连续服务能力。
• 提升了系统间通信可靠性，无论是从通信本身的可靠性上（请求响应机制、重试），还是业务意义上（处理顺序、事务、失败策略），都相比RPC等方式有所增强
• 增强了系统的扩展能力，通过消息队列处理的业务，消费端的处理能力如果不够，可以随时添加几个消费者来处理，从而可以直接扩展系统的业务处理能力。

2.4、SOA系统的落地方式：

SOA的落地方式与水平，跟企业 IT 特点、服务能力和发展阶段直接相关。目前常见的落地方式主要有分布式服务化和集中式管理两种：

（1）分布式服务化：互联网类型的企业，业务与技术发展快，数据基数与增量都大，并发访问量高，系统间依赖关系复杂、调用频繁，分布式服务化与服务治理迫在眉睫。通过统一的服务化技术手段，进一步实现服务的注册与寻址、服务调用关系查找、服务调用与消息处理监控、服务质量与服务降级等等。现有的一些分布式服务化技术有dubbo(基于Java)、finagle(基于scala) 和 ICE（跨平台）等等。

（2）ESB集中式管理化：传统企业的IT内部遗留系统包袱较重，资源整合很大一部分是需要打通新旧技术体系的任督二脉，所以更偏重于以 ESB 作为基础支撑技术，以整合集成为核心，将各个新旧系统的业务能力逐渐的在 ESB 容器上聚合和集成起来。

2.5、什么是 ESB：

前面多次提到了 ESB，那么究竟什么是 ESB呢？ESB 就是采用了 “总线” 的模式来管理和简化应用之间的集成拓扑结构，是一种在松散耦合的服务和应用之间标准的集成方式，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通。

既然 ESB 和 EAI 都是实现不同系统间的数据格式转换与系统间的连通，那么 ESB 究竟和 EAI 有什么区别呢？ESB 相比 EAI 更加松散耦合，而且加入了业务流程、数据格式转换、以及更多的消息处理方式（基于内容和规则的消息路由、消息过滤、消息合并和消息的重新排序），对比 EAI平台，ESB做了 标准数据/接口 到 各个技术和系统的数据/接口 之间的适配工作。一个企业不用 ESB 没有问题，但是用ESB可以更好的解决不同异构系统的连接问题。出现ESB后，EAI 进入了一个新的阶段，就是ESB阶段。 

​如上图，找到和管理服务可以借助ESB服务总线能力来完成，而组装和编排服务可以借助BPM管理软件来完成。而 ESB + BPM 也是常说的实现SOA架构思想的关键平台。ESB总线需要同时考虑解决集成和解耦两类问题，而 ESB 总线产品很多是由原有的 EAI 和消息中间件产品发展而来，因此更多的强调的是服务或消息集成，而弱化了SOA更加重要的一个能力即服务共享。

• （1）集成：解决的是业务和流程上的协同问题，服务不一定就能复用
• （2）复用：解决的是底层共有组件模块提取后能力开放问题，重点是可复用

​从上面图可以看到，对于横向交互协同的接口，更多的是解决跨系统的集成问题，而对于系统中纵向使用的共享能力接口，在共享能力平台化后，则接口服务可重用，更多的解决就是服务层面的问题。对于服务重用问题的解决，更多都是伴随着共性能力下沉产生的，然而当前大部分企业将SOA简单理解为了 ESB 和集成平台，更多用SOA去解决集成的问题，而忘记了 SOA架构思想的本质仍然是共性业务能力下降，上层应用灵活编排。

2.6、没有 ESB 能否叫 SOA 架构：

ESB 和 SOA 本身没有关系。SOA 面向服务的思想是面向对象思想以后的一种新的思想模式，其核心特点就是以松耦合、粗粒度的服务形式来构建软件。作为一种思想，SOA 不涉及任何具体的技术和平台，但是思想存在一个实现的问题，人们发现 ESB 是实现 SOA 的一个最佳方式，因此 ESB 成为 SOA 的技术基础。

在 SOA 架构中，由于单个系统被拆分成了多个小系统，且服务之间相互访问，调用链将会变得非常复杂，逻辑变得混乱；并且不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务。那么引入企业服务总线 ESB 的好处就体现出来了，通过 ESB 统一进行访问协议转换，屏蔽服务接口的访问差异，服务与服务之间也通过 ESB 来相互调用，以此降低系统的耦合程度。（对于 ESB 的重要性，可以简单阅读这篇文章：https://zato.io/docs/intro/esb-soa-cn.html）

当然，不用 ESB，不能说你的系统就没有 SOA，只是遗留系统暴露的接口服务没有进行统一的管控和治理，也就是说对于接口服务的治理水平会比较弱，但是只要你暴露的接口服务是粗粒度和可复用的，同样可以共享给上层业务系统或应用使用。正如没有使用 BPM，同样也可以实践 SOA 编排思想，只是你需要通过自己写代码去编排服务，而不是通过 BPM 软件去可视化编排服务。反之同样的道理，不用简单理解使用了 ESB 就是 SOA 架构。比如你使用了ESB，接入了一堆没有经过标准化，不符合粗粒度特点的接口，这些接口本身混乱也没有任何服务价值。上层新业务开发也不能使用这些接口服务，那么这个时候你的 ESB 就仅仅是一个接口平台，也没有实现任何的SOA架构思想。

到底系统是不是SOA，关键看是否以服务的思想进行构建，不是简单的说系统划分多少多少层次就是 SOA 化了，而是已经要用粗粒度服务的形式来构建系统。那到底什么是服务？从表现形式上讲，服务可以是webService，可以是传统的com组件，可以是一个jar，到底是什么不重要，重要的是这些表现形式是用服务的思想进行划分。 

2.7、EAI 系统与 SOA 系统的比较：

2.7.1、EAI 系统和 SOA 系统的相同点：

• 两者在技术层面都有统一的数据和接口定义，可以方便连接各个异构系统。但是， SOA 提供的是一种开放的标准的异构接口互联互通技术，相比于 EAI 更加开放灵活
• 都兼容各组件技术（CORBA、COM、EJB），远程调用技术(RMI)
• 提供将简单服务或者操作编排组织成更复杂的服务或者操作。

2.7.2、EAI 系统和 SOA 系统的不同点：

（1）集成的本质（可以理解为 SOA = ESB + EAI）：

• EAI 的集成方式从本质而言是基于消息的集成，因此 EAI 的各组成部件，如适配器与hub，都带有消息转换与消息路由的功能，在 EAI 的运作过程中，单个应用系统只关心其与 EAI 连接部分消息的输入与输出，不关心具体的业务处理，业务处理都是在应用系统内部完成的。
• SOA 的集成方式本质是对业务功能服务化后根据业务流程进行编排，是真正意义上的基于功能服务的集成。当然 SOA 中同样包含了基于消息集成的功能。因此基于 SOA 的集成方式比 EAI 的集成方式适用范围更广。(服务集成更加标准化，更加体现业务驱动)

（2）集成对象的颗粒度：

• EAI 从应用系统的层面去看待企业已有信息资源，集成单元是企业的每个应用系统。EAI 工作的目标就是，通过为这些已有的应用系统提供一种中间沟通方式，让应用系统之间可以进行数据的共享与交换，从而盘活这一个个独立的 “信息孤岛”。
• SOA 从提供服务、使用服务的角度去看待企业已有的信息资源。在这种方式下，同样的一种资源既可能是服务提供者，也同样可以是服务使用者；在这种方式下，一个应用模块可能只提供一种服务，因此被封装成一个服务，也可能由于提供了多种服务，而需要进一步划分。

（3）重用性：

• 通过 EAI 方式实现企业应用集成，不同系统的通信是通过中央消息主干线进行的。应用程序使用适配器将消息发布到总线，消息通过总线流动到指定的应用程序中。总线是消息流动的通道，捆绑在应用系统端的适配器负责完成消息在应用系统端的格式与符合总线标准的格式之间转换。其开发的适配器、中间层消息转换规则和消息路由都是紧耦合的，对于每一个应用系统，都需要单独为其开发符合应用系统自身要求的适配器，而由于没有遵循统一的标准，这些适配器是无法通用的。因此当某个应用系统进行比较大的改动时，则有可能存在对适配器的改造已经不能满足系统变更需求的情况，此时甚至有可能会牵涉到对BUS总线的修改，给企业信息架构带来很大的风险。
• 在 SOA 架构下，各个服务是以完全独立的方式并通过服务目录暴露在 SOA 集成平台上的，当新集成进来的应用系统需要使用现有的某个服务时，可以直接使用，无需再次开发，即服务是可重用的，只需用开发目前还没有的业务功能服务，这样可以充分利用现有的资源，降低成本。并且从 ESB 和 EAI 的总线工作过程上的区别可以看出 ESB 承担了更多的责任，做了更多的事情，为集成后的系统提供了完善、坚固的底层支持。

（4）开放性：

• SOA 提供的服务接口是开放的，可以在 SOA 平台外以异构的接口调用 SOA 平台上的服务。
• EAI 的接口是私有的，只能在 EAI 平台内部调用，EAI 提供一种标准的接口来调用异构系统的功能。 

（5）架构的侧重点：

• SOA 目的是基于分布式的高复用性服务集合来构建企业应用系统，强调服务的复用性，实现异构服务接口的互联互通。
• EAI 目的是把各个系统的异构接口封装为统一的接口，只提供连接手段，流程编排手段。强调集成异构系统，不强调服务复用。

（6）架构设计：

• SOA的服务分业务服务，组件服务，基础服务多个层次；设计思路更强调从上到下，即从业务到技术；
• EAI 中适配器相当于基础服务。设计思路一般是从下而上，即从技术到业务。

因此，使用 SOA 比使用 EAI 更经济，尤其在多个应用系统相互集成的复杂场景下，SOA的优点将更加突出。从技术层面上看，SOA 是旧的组件技术和 EAI 技术的组合和升级。而实施 SOA 项目，最主要的还是在设计层面上如何把业务系统划分为粒度合适，高聚合低耦合，复用性好又兼顾性能的服务集合；

2.8、SOA 架构向微服务的转变：

在前面的介绍中说到，SOA 可以解决单体架构存在的大部分问题，但是发展到今天，SOA 已经很少被人提及了，很多企业在完成 SOA 改造之后的若干年间，受到后续各种新系统的冲击，而大部分企业最终都没能坚守住自己的 SOA 体系，又回到了烟囱架构下的野蛮生长状态，这其中的原因主要是：

（1）沟通与协作成本高：新系统迫于业务需求和市场压力，急需上线，对负责的团队而言，与周边系统的对接和调试属于外部不可控因素，团队总是倾向于在内部可控的范围内解决问题，因此会刻意避开对外部服务的依赖，选择自建相关功能。这样一来，系统间的交互会向着衰减的方向发展，重复建设也因此随之蔓延；

（2）组织架构制约：团队往往缺乏为响应其他系统的诉求而改造和升级自身服务的意愿，因为新系统与他们没有直接的利益关系，企业也缺乏适当的奖惩机制促使各团队之间的积极协作，本质上，这是组织架构决定的；

（3）缺乏长效机制：SOA 改造常常是作为一个项目实施的，项目结束之后就不再有专门的组织和团队对 SOA 架构进行持续把控了，后续新的系统在融入SOA 生态时受到的支持就减弱了，而新系统本身提供的服务也缺乏必要的梳理和管控，有的新系统甚至不对外提供服务。

这些问题并不是 SOA 自身的问题，而是一些普遍的现实问题，也是治理烟囱架构过程中遇到的深层次问题，这些问题阻碍了 SOA 在企业的落地和持续发展。但是抛开组织架构的原因，从技术角度上看，SOA 同样也存在缺点：

（1）虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

（2）SOA 是对异构系统的服务化，但抽取的服务的粒度过大，系统与服务之间耦合性高

• SOA适用于企业级的应用，颗粒度比较大，服务细化到子系统或者模块。但是这些子系统或者模块之间有很多冗余的功能，可能会造成资源浪费，也增加维护成本。比如图片的存储，每个子系统都有自己的一套代码，甚至存在各自的不同的服务器上。
• 微服务适用于社会级的应用，颗粒度更细，甚至细化到具体的功能，比如图片存储、短信发送、统一支付等等。类似阿里巴巴“大中台”的思路，整合资源，合理分配。

（3）在 SOA 架构中，随着数据库进一步拆分、登录注册等服务进一步独立，就会出现服务划分的越细，部署、管理、监控越麻烦的问题。

• 系统的发展一般是根据用户规模来的，当用户达到一定规模，旧的系统就会达到访问瓶颈，要想扩大规模就必须对旧的系统进行升级，否则系统的质量无法得到保证，甚至出现系统瘫痪，而新系统要想适应更大的用户规模，一个最有效的方法就是分工。用户规模越大就需要越细的分工，如果将分工理解为服务，将分工的粗细理解为服务的颗粒度，那么更大的用户规模就需要更小颗粒度的服务。
• 针对大量微小服务部署、管理困难的情况，随着容器化技术Docker的兴起，很好地解决了 SOA 的痛点，也推动 SOA 往更细的粒度进行拆分。通过docker，可以很简单地把服务打包为镜像，然后通过K8S动态分发到需要部署的相关服务的机器上，直接启动docker镜像就可以把服务启动起来，使服务的部署和运维变得简单。

综上，在 SOA 思想的基础上，发展出了微服务的架构。而其中，Docker 的兴起与成熟是最根本的推动因素，技术是第一生产力，应用 Docker 技术，不依赖任何服务器和数据模型，可以通过自动化方式独立部署，每个服务运行在自己的进程中。

3、微服务架构：

3.1、什么是微服务：

微服务是 SOA 思想的一种提炼，它强调的重点之一就是业务系统彻底的组件化和服务化，通过有效的拆分应用，实现敏捷开发和部署。原有的单个业务系统被拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间松耦合，并且使用轻量级协议进行通信（备注：SOA是对异构系统的服务化，微服务专注服务的拆分）

微服务的理论基础是康威法则，康威法则的真正含义就在于，在项目达到一定规模后，团队规模和单个项目复杂度之间产生矛盾，生产力低下。多个团队维护同一个项目，在集成时往往需要各个团队的相互配合，而如果将一个项目拆分成多个小项目后，每个团队只负责该一个小项目，就能避免许多不必要的麻烦。所以说架构师不仅仅是要关心技术架构还要关心组织架构。微服务重在独立布署和独立业务，但并不是越小越好，而是通过团队规模和业务复杂度由粗到细的划分过程，所遵循的原则是松耦合和高内聚。正如 Neflix 前总监：微服务架构本质上是组织架构的重组。

3.2、微服务的特点：

• 每个微服务有自己私有的数据库持久化业务数据，并且只能访问自己的数据库，而不能访问其它服务的数据库
• 如果一个事务中需要操作多个数据库，这种情况也不能直接访问其它微服务的数据库，只能通过对于微服务提供的接口进行操作。
• 数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的技术。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理

3.3、微服务主要解决的问题与场景：

（1）服务复用，降低成本。企业内部不同的应用间都会有一些通用的东西，比如通知、授权等，将这些服务复用起来，避免重复造轮子

（2）支持快速迭代。单体应用无法满足业务增长的需求，DevOps 理念就是要支持快速迭代，如果应用架构不改，是无法在 DevOps 实践中实现快速迭代的。拆分成微服务之后，针对特定服务发布，影响小，风险小，成本低。频繁发布版本，快速交付需求。

（3）高可用、高弹性和高性能。解决单体应用的业务可靠性、稳定性问题，随着时间的推移越来越多的问题。

3.4、微服务的缺点：

（1）系统维护：服务数量比单体服务更多，部署、管理的工作量很大

（2）稳定性：稳定性下降，一个服务出现故障 ，可能导致整个系统挂掉，同时整个应用被分散成多个服务，定位故障点非常困难。

（3）系统测试：原本单个程序的测试变为服务间调用的测试，测试变得更加复杂。微服务化之后，单一模块无法独立完成业务功能，而集成测试会在非常靠后的时候才能做，就要求需要大量引入 API 自动化测试等测试方法。

（4）开发方面：

• 项目初期，业务简单与用户量小，单体项目的开发成本最低，开发效率最高，而选择微服务架构，需要准备很多资源，开发成本较高，开发的效率也就很低。
• 如果当前规模恰到好处，把服务迸一步拆分不仅不会降低复杂性，反而会让系统变得更复杂。所以不是所有的应用程序都适合被拆分成微服务。同时如果拆分不好，会大量引入分布式事务，处理起来会比较麻烦；
• 如果应用程序要求各个组件和服务之间紧密集成，比如需要快速处理实时数据的应用程序。在服务之间添加新链路会导致处理速度变慢。   
• CAP原则：由于服务无状态和引入了分布式，较难解决事务一致性问题

（解决上面四个问题的核心在于：持续部署、全链路监控、自动化测试、服务拆分策略）

3.5、微服务与SOA的区别：

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

（1）SOA 和微服务是一脉相承的，微服务是 SOA 思想的一种提炼，是经过良好架构设计的 SOA，使用一系列微小服务来实现单个应用的方式，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署。

（2）微服务与敏捷开发的思想高度结合在一起，微服务框架将能够带来更大的敏捷性，并为构建应用提供更轻量级、更高效率的开发，而 SOA 更适合大型企业中的业务过程编排、应用集成。

微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果企业内部快速交付的基础设施比较薄弱，系统拆分为微服务后，部署的成本呈指数上升，整体就难以达到快速交付的要求。

（3）从服务粒度上，SOA 的服务粒度要粗一些，而微服务倡导服务的细粒度，专注于服务的拆分，重用组合，服务粒度足够小到不能再进行拆分，而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度。微服务是以 SOA 的思想进入到单个业务系统内部实现**彻底的组件化和服务化**，原有的单个业务系统拆分为多个可以独立开发、设计、运行和运维的小应用，这些小应用可独立地进行开发、管理和加速，应用之间通过服务完成交互和集成，每个小应用除了完成本身的业务功能外，还需要消费外部其它应用暴露的服务，同时也将自身的能力朝外部发布为服务。

例如，对一个大型企业来说，“员工管理系统”就是一个 SOA 架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工福利管理”等更多服务。

（4）去中心化：SOA 注重的是系统集成，而微服务关注的完全分离，微服务架构采用去中心化思想，服务之间采用统一的协议和格式，例如 REST、RPC 等轻量协议通信，相比 ESB 更轻量。为了统一管理微服务系统，可以部署一个统一的网关，作为系统的唯一入口。网关封装了系统内部架构，为每个客户端提供一个定制的API。除此之外，网关还可以用于身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。两者的架构如下图所示：

SOA架构：（备注：数据总线一般使用 ESB，通过 ESB 连接各个服务节点，并做了消息的转化解释和路由工作，让不同的服务互联互通）

微服务架构（基础版本）：

SOA 更适合需要与许多其他应用程序集成的大型复杂企业的应用程序环境，小型应用程序不适合 SOA 架构，因为它们不需要消息中间件组件。而微服务架构，更适合于较小和良好的分割，基于Web的系统。如果你开发的是互联网应用，并且没有历史遗留问题，请优先考虑采用微服务架构。

3.6、SOA 的 ESB 与微服务的 API 网关：

（1）企业服务总线 ESB：简单来说，ESB 就是一个用来连接各个服务节点的管道，为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；

（2）API网关：API 网关是一个服务器，为系统的唯一入口。网关封装了系统内部架构，为每个客户端提供一个定制的API。除此之外，网关还可以用于身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。API 网关的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供 REST/RPC的访问API。服务端通过API-GW注册和管理服务。 

简单来说，API 网关就是将微服务提供的所有 API 接口服务能力全部汇聚进来，统一接入进行管理，通过网关统一拦截，实现对 API 接口的安全、日志、限流熔断等共性需求。内部的微服务对外部访问来说位置透明，外部应用只需和网关交互。从这里我们就可以看到，API 网关和 SOA 架构的 ESB 总线是类似的，这些关键能力本身也是 ESB 服务总线的能力，但是 ESB 服务总线由于要考虑遗留系统的接入，因此增加了：

• 大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
• 进行数据的复制映射，路由等能力

对于微服务架构，说的最多的就是去中心化的架构，认为 ESB 中心化架构模式已经过时。而实际上经过上面分析可以看到，在微服务架构里面的 API 网关仍然是中心化的架构模式，所有的API接口都要经过网关这个点。那微服务架构里面是否有去中心化的架构？当然是有的，也就是我们常说的微服务模块之间可以通过服务注册中心来实现服务发现查找，服务间的点对点调用即使去中心化的。

• 中心化架构  -->  走网关进行接口服务暴露和共享交互
• 非中心化架构 --> 走微服务里面的服务注册中心进行接口交互

如果一个单体拆分为微服务后，完全不需要和外部应用打交道，也不需要共享自己的接口能力，那么这个微服务体系里面就不需要用 API 网关，仅仅使用服务注册中心即可，通过服务注册中心实现完全的去中心化和接口调用更高的性能。

前面介绍 ESB 的时候谈到解决两个层面的问题，一个是集成，一个是共享。那么转移到微服务架构体系后，集成的问题通过非中心化架构完全可以解决，而对于共享问题仍然需要 API 网关来解决。

3.7、大规模使用微服务条件：

​    前面介绍了微服务的这么多好处，那么微服务一定是“银弹”吗？答案是否定的，要大规模使用微服务前，一定要先考虑清楚微服务能否解决当前项目中遇到的瓶颈：

• （1）首先，判断是否要做微服务。现在普遍的现象是大家没想清楚为什么要做微服务就开始做了。如果只是做了服务拆分而并没有复用的需求，或者没有高并发、弹性甚至是分布式的需求，做微服务的意义也不大。
• （2）第二，如果你不能构建一个结构良好的单体，那么你凭什么认为微服务就是答案？如果你搞不定单体应用，别指望微服务能够拯救你！微服务只是将复杂性被转移，但并未被消除单体中存在的问题。

接下来，如果觉得微服务可以解决当前项目中遇到的难题，那么则需要考虑，公司是否有能够支持实施微服务架构的基础设施，尤其是容器技术、自动化部署、自动化测试，这些不完备，微服务形同虚设，不会带来什么质的提升。微服务的先决条件如下：

• （1）快速的环境提供能力：依赖于云计算、容器技术，快速交付环境。
• （2）快速的应用部署能力：基础设施自动化，提供快速的部署能力。因为随着单体应用被拆分为多个微服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大，必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。
• （3）基本的监控能力：包括基础的技术监控和业务监控。采用了微服务后，也意味着服务之间的调用关系会比以前复杂，在调用链路上发生故障的几率也就随之增大，所以监控能力是一项非常关键的条件。
• （4）Devops文化：具有良好的持续交付能力，包括全链路追踪、快速环境提供和部署等，还需要快速的反应能力（对问题、故障的快速响应），开发和运维的协同工作。

然后，微服务对组织架构与开发人员能力的也有一定的要求：

• （1）组织架构上，是否能够按业务能力来划分服务与组建微服务团队
• （2）人员规模上，如果系统的开发人员小于100个，那么要根据实际情况决定是否使用微服务。 通常，这类工程组织有一个共同的关注点：创建可靠且稳定的系统，为业务交付价值，所有这些都需要借助紧张的工程资源。
• （3）技术选型上，能保证选取的微服务架构技术能够解决绝大部分微服务必须要解决的技术点，选型的微服务框架是否有熟练使用以及了解、熟悉其原理的同学，一个团队摸着石头过河必然会很痛苦，效率也无法保证

3.8、如何解决微服务带来的问题：

3.8.1、API 网关：

对于微服务的管理和治理问题，可以使用 API 网关来解决，类似于 ESB 服务总线，只是更加轻量和高性能。

前面也提到了API网关和ESB的区别了，这里再总结一下，API 网关和 ESB 的重要区别点在于 API 网关更加轻量和高性能，它不需要去考虑太多遗留系统和诸多协议的适配，其次也不需要考虑服务集成过程中的大量数据转换和映射。同时为了提升服务网关的性能，一般API网关在实现过程中不会去记录详细的数据传输日志，或者类似Dubbo架构数据传输根本就不会通过API网关。

API 网关作为系统的唯一入口，封装内部系统的架构，并且提供 API 给各个客户端。它的最大优点是，客户端只需同网关交互，而不必调用特定的服务，所有的请求都首先经过 API 网关，然后由它将请求路由到合适的微服务。有了网关之后，由网关对服务代理与路由、流量控制、负载均衡、安全与访问控制、日志等公共层面的工作进行统一配置和处理，而不需要每个微服务 API 实现时都去考虑，从而解放开发者去把精力专注与自己业务逻辑的处理在具体逻辑的代码。

但是 API 网关也存在不足之处，在微服务这种去中心化的架构中，网关又成了一个中心点或瓶颈点，它增加了一个我们必须开发、部署和维护的高可用组件。正是由于这个原因，在网关设计时必须考虑即使 API 网关宕机也不要影响到服务的调用和运行，所以服务网关需要有数据缓存能力，通过返回缓存数据或默认数据屏蔽后端服务的失败。

在服务的调用方式上面，网关也有一定的要求，API 网关最好是支持支持异步、I/O 非阻塞的。如果服务是同步调用，可以理解为微服务模块之间是没有彻底解耦的，即如果A依赖B提供的API，如果B提供的服务不可用将直接影响到A不可用，除非同步服务调用在API网关层或客户端做了相应的缓存。因此为了彻底解耦，在微服务调用上更建议选择异步方式进行。而对于 API 网关需要通过底层多个细粒度的 API 组合的场景，推荐采用响应式编程模型进行而不是传统的异步回调方法组合代码。其原因除了采用回调方式导致的代码混乱外，还有就是对于 API 组合本身可能存在并行或先后调用，对于采用回调方式往往很难控制。

3.8.2、服务注册中心：

        前面说过，微服务独立部署、具有清晰的边界，服务之间通过远程调用来构建复杂的业务功能。那么使用服务注册中心可以解决微服务中的哪些问题呢？服务注册中心又是什么呢？

        服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。

（1）服务注册中心的核心功能有以下几个：

• 服务注册：服务实例将自身服务信息注册到注册中心
• 服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
• 服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

（2）服务注册中心主要解决了如下两个重要问题：

• 屏蔽、解耦服务之间相互依赖的细节：服务之间的远程调用必须要知道对方的IP、端口信息。而调用方直接依赖IP、端口的调用方式存在明显的问题，如被调用的IP、端口变化后，调用方法也要同步修改。通过服务发现，将服务之间IP与端口的依赖转化为服务名的依赖，服务名可以根据具体微服务业务来做标识，因此，屏蔽、解耦服务之间的依赖细节是服务发现与注册解决的第一个问题。
• 对微服务进行动态管理：在微服务架构中，服务数量多且相互间的依赖也错综复杂，无论是服务主动停止、意外挂掉，还是因为流量增加对服务实现进行扩容，这些服务数据或状态上的动态变化，都需要尽快的通知到被调用方，被调用方才采取相应的措施。因此，对于服务注册中心要实时管理服务的数据与状态，包括服务的注册上线、服务主动下线，异常服务的剔除。

（3）服务的发现与注册的实现模式：

对于服务发现与注册一般有两种实现模式：服务器端的发现模式 和 客户端的发现模式，两种模式各有优缺点，也适用于不同的场景，这里就不展开进行详细说明了。

（4）服务注册表：

微服务架构中，所有的服务启动后都通过注册中心来注册自己，同时把注册中心里面的服务信息拉回本地，后续调用时就直接检查本地的服务和节点信息来进行服务节点的调用。每个服务节点都会来注册中心进行服务注册，那数据如何在服务端进行保存呢，其实就是注册表，服务注册的时候把自己的信息上报上来，然后注册中心把注册表，返回给客户端，那服务之间就知道要调用服务的节点了。

服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的服务地址，然而，这些信息最终会过时，客户端也就无法发现服务实例。因此，服务注册表会包含若干服务端，使用复制协议保持一致性。并且服务注册表不能是单点，否则存在单点故障，当服务注册表有多台服务器的时候。同时需要考虑服务注册库信息在多台机器上的实时同步和一致。

3.8.3、配置中心：

​    　配置中心是将系统中对配置信息的管理作为一个新的应用功能模块，区别于传统的配置信息分散到系统各个角落方式，配置中心对配置信息进行集中统一管理，并且提供额外功能。通过配置中心，可以使得配置标准化、格式统一化，同时还可以满足不同环境下配置信息的不同、配置信息修改之后实时生效等需求，快速响应变化，通过审计功能还可以追溯问题。

3.8.4、服务通信：

在单体应用中，各模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是微服务应用是运行在多台机器上的，一般来说，每个服务实例都是一个进程。微服务必须使用进程间通信机制来交互。而常见的通信协议主要有 RPC 和 REST 协议。

REST 和 RPC 都常用于微服务架构中，微服务的好处之一，就是不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦。 但是，如果没有统一的通信框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等 “业务之外” 的重复技术劳动，造成整体的低效。所以，统一通信框架把上述 “业务之外” 的技术劳动统一处理，是服务化首要解决的问题。

（1）REST：

REST 是一种架构风格，指的是一组架构约束条件和原则，满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源，它是通过 HTTP 协议实现，使用 HTTP 协议处理数据通信，更标准，更通用，因为无论哪种语言都支持 http 协议。常见的 http API 都可以称为Rest 接口。REST 提供了一系列架构系统参数，作为整体使用，强调组件交互的扩展性、接口的通用性、组件的独立部署、以及减少交互延迟的中间件，它强化安全，也能封装遗留系统。

（2）RPC：

RPC 是一种进程间通信方式。允许像调用本地服务一样调用远程服务，通信协议大多采用二进制方式。RPC 框架的目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发者在使用时只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率。常见的 RPC 框架图如下：

RPC 框架要做到的最基本的几件事：

• 解决通讯的问题：主要通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
• 解决寻址的问题，服务端如何确定客户端要调用的函数：在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表，ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
• 如何序列化和反序列化：客户端和服务端交互时，方法的参数和结果需要通过底层的网络协议如TCP传递，由于网络协议是基于二进制的，那么这些值需要序列化成二进制的形式，通过寻址和传输将序列化的二进制发送目标服务器。目标服务器接收到数据时，需要对数据进行反序列化。序列化和反序列化的速度也会影响远程调用的效率。
• 如何进行网络传输（选择何种网络协议）：多数 RPC 框架选择 TCP 作为传输协议，也有部分选择HTTP。如 gRPC 使用 HTTP2。不同的协议各有利弊。TCP更加高效，而HTTP在实际应用中更加的灵活。

（3）RPC 与 REST 的对比：

• 灵活性方面：在微服务架构中，各个服务间千差万别，REST 的调用和测试都很方便，但使用 RPC 则会有很多约束。
• 性能方面：RPC 协议性能更高，如果算上序列化，吞吐量大概能达到 REST 的二倍，响应时间也更为出色。
• 开放与通用性：REST 通过 http 实现，相对更加规范与通用，无论哪种语言都支持 http 协议。而如果 RPC 需要对外开放的话，需要进一步处理。所以如果是对外开放的 API，一般使用 REST 协议，内部服务的调用则采用性能更高的RPC方式。
• 代码的耦合度：RPC 与代码的耦合度高，而 REST 对代码松散耦合。

3.8.5、容错设计：

（1）限流熔断：使用熔断器，当下游的服务发生了一定数量的失败后，熔断器打开，接下来的请求快速返回失败。过一段时间后再来判断下游服务是否已恢复正常，重置熔断器。

（2）资源隔离：隔离是指将系统或资源分割开，保证系统发生故障时，能限定传播范围和影响范围，即发生故障后不会出现滚雪球效应，从而保证只有出问题的服务不可用，其他服务还是可用的，保障服务间的相互不影响和可用性。常见的隔离手段有资源隔离、线程隔离、进程隔离、集群隔离、机房隔离、读写隔离、快慢隔离、动静隔离等。

（3）服务降级：当访问量剧增、服务出现问题（入响应时间长或者不响应）或者非核心服务影响到核心流程的性能时，仍要保证服务还是可用的，即使是有损服务。

（4）服务限流：限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速来包塑系统，一旦达到限制速率则可以进行拒绝服务、排队、等待、降级等操作，通过拒绝处理过载的请求保证系统的可用。

（5）幂等：当用户多次请求同一事件时，得到的结果永远是同一个。

（6）超时：超时时间对于调用服务来说非常重要，超时时间设置太长可能会把整体系统拖慢，而设置短了又会造成调用服务未完成而返回，所以需要根据业务场景进行分析，选择一个恰当的超时设定值

3.8.6、服务治理：

（1）服务监控与告警：做好监控和告警，Metrics 监控，健康检查和告警通知等

（2）链路跟踪：通过链路跟踪定位到哪个服务出现问题（CAT、zipkin、pinpoint）

（3）日志分析平台：链路跟踪只能定位到哪个服务出现问题，查找具体的错误信息的能力则需要由日志分析组件来提供

3.8.7、自动化测试：

即任何一个组件，当他依赖的外部其它应用组件越多的时候，整个集成，部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量，二是增加出错概率。所以必须引进自动化测试，自动化测试包括代码级别的单元测试、单个系统的集成测试、系统间的接口测试。

3.9、服务拆分：

微服务架构的关键不在于具体的实现，而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。微服务架构首先要关注的不是 RPC、Service Discovery 这些概念，也不是 Eureka、Zipkin 这些技术框架，而是服务的边界、职责划分，划分错误就会陷入大量的服务间的相互调用和分布式事务中，这种情况微服务带来的不是便利而是麻烦。

微服务拆分设计，作为微服务架构最核心的环节，主要是对服务的横向拆分。服务拆分就是将一个完整的业务系统解耦为服务，服务需要职责单一，服务之间没有耦合关系，能够独立开发和维护。服务拆分不是一蹴而就的，需要在开发过程中不断地理清边界，在完全理清服务之前，尽量推迟对服务的拆分，尤其是对数据库的拆分。如果服务拆分的不合理，非但不能解决当前项目中的问题，还会引起新的问题。

（1）常用的方式有：基于业务逻辑拆分、基于可扩展拆分、基于可靠性拆分、基于性能拆分

（2）服务拆分方法：

拆分方法需要根据遗留系统的状态，通常分为绞杀者与修缮者两种模式：

• 绞杀者模式：指在遗留系统外围，将新功能用新的方式构建为新的服务。随着时间的推移，新的服务逐渐“绞杀”老的遗留系统。对于那些老旧庞大难以更改的遗留系统，推荐采用绞杀者模式。
• 修缮者模式：就如修房或修路一样，将老旧待修缮的部分进行隔离，用新的方式对其进行单独修复。修复的同时，需保证与其他部分仍能协同功能。

        真正有挑战的问题：如何保证拆对了？拆分不能没有目标，尤其在具有风险的架构层次拆分更需谨慎。那么我们如何验证拆分的结果和收益？或许可以提高开发效率，交付速度快，上线快，宕机时间也短，还能提高开发质量，可扩展性好，稳定，维护成本低，新人成长快，团队容易掌握等等。然而软件开发是一个复杂的事情，拆分可能引起多个维度的变化，度量的难度在于如何准确定位由拆分这一单一因素引起的价值的变化（增加或降低）。其实要回答这个问题，还是要回到拆分之初：为什么而拆？ 有因为政治原因拆的、业务发展需要的、系统集成驱动的等等；有因之而成功的，也有因之而失败的。拆并不是一件容易的事，有诸多的因素。我认为不管表象是什么，拆之前需要弄清拆分的价值所在，这也是我们可以保证拆分结果的源头。

（3）领域驱动设计DDD：Domain Driven Design 

DDD 是一种架构设计方法，从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。DDD 可以用来指导微服务的拆分，建立优良的领域模型，通过Spring Cloud 或 Dubbo 等微服务技术将领域模型实现成应用代码。

四、服务网格-ServiceMesh：

参考文章：https://developer.aliyun.com/article/697771

1、边车模式：

边车：就是在原来二轮摩托车旁边增加一个座位成了三轮摩托车，增加的一部分称为边车，通过边车来达到拓展功能的目的，比如行驶更加稳定、拉更多的人和货物，坐在边车上的人可以给驾驶员指路等

边车模式：对现有服务增加额外的功能，这些功能并不影响业务逻辑（比如增加日志，限流、熔断、服务的注册和服务发现等），类似于程序中的控制和业务逻辑分离（Controller 和 Service 层分离），大大降低服务之间的耦合度和复杂性，提升扩展性。在设计上，边车模式与网关模式有类似之处，但是其粒度更细。其为每个服务都配备一个“边车”，这个 “边车“ 可以理解为一个代理 agent，这个服务所有的通信都是通过这个 agent 来完成的，而 agent 同服务一起创建，一起销毁。这与分布式和微服务架构完美契合，真正的实现了控制和逻辑的分离与解耦。

1.1、边车模式可以解决什么问题？为什么使用边车模式：

（1）控制与逻辑分离的问题：将所有的服务进行统一管理，让开发人员更专注于复杂的业务开发，对于日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断、鉴权、访问控制和服务调用等本质上与业务服务关系不大的功能，提取成一个标准化的 Sidecar ，通过 Sidecar 代理来与其他系统进行交互。这也符合单一职责原则，服务只负责实现好自己的业务逻辑，其他的控制功能就交给其他组件来实现，真正的实现了控制和逻辑的分离与解耦。

（2）解决服务之间调用越来越复杂的问题：随着分布式架构越来越复杂和微服务越拆越细，我们越来越迫切的希望有一个统一的控制面来管理我们的微服务，来帮助我们维护和管理所有微服务，这时传统开发层面上的控制就远远不够了，而边车模式可以很好的解决这个问题。

1.2、边车模式的实现方法：

（1）通过 SDK、LIB 等软件包的形式，在开发时引入该软件包依赖，使其与业务服务集成起来。这种方法可以与应用密切集成，提高资源利用率并且提高应用性能。但是这种方法是对代码有侵入的，受到编程语言和软件开发人员水平的限制，但当该依赖有 bug 或者需要升级时，业务代码需要重新编译和发布。同时，如果该依赖宣布停止维护或者闭源，那么会给该服务带来不小的影响。

（2）以 Sidecar 的形式，在运维的时候与应用服务集成在一起。这种方式对应用服务没有侵入性，不受编程语言和开发人员水平的限制，做到了控制与逻辑分开部署。但是会增加应用延迟，并且管理和部署的复杂度会增加。

2、Service Mesh 服务网格：

Service Mesh 服务网格诞生的契机，正是边车模式有效的分离了系统控制和业务逻辑，可以对所有的服务进行统一管理，让开发人员更专注于业务开发，显著的提升开发效率。开发人员一直试图将上文中我们提到的功能（如：流量控制、服务注册、服务发现、服务限流、服务熔断等）提取成一个标准化的 Sidecar ，通过 Sidecar 代理来与其他系统进行交互，简化业务开发和运维。而随着分布式架构和微服务的发展，这一需求日益凸显。

Service Mesh是一个专用的基础设施层，它的目标是在微服务架构中实现可靠、快速和安全的服务间调用。 它不是一个 “服务的网格”，而是一个服务可以插入其中的“代理的网格”，以实现网络的完全抽象化。通过Service Mesh 帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制，业务所有的流量都转发到Service Mesh的代理服务中。 不仅如此，Service Mesh还承担了微服务框架所有的功能，包括服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速等。不同的是，Service Mesh强调的是通过独立的进程代理的方式，除此之外，还承担了上报日志、监控的责任。

总结一下，Service Mesh 具有如下优点：

• 屏蔽分布式系统通信的复杂性（负载均衡、服务发现、认证授权、监控追踪、流量控制等等），服务只用关注业务逻辑；
• 真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
• 对应用透明，Service Mesh 组件可以单独升级。

当然，Service Mesh 也有局限性：

• Service Mesh 以代理模式计算并转发请求，由于网络中多了一跳，增加了通信系统性能的损耗和访问的延迟，也增加系统资源开销；
• Service Mesh 接管了网络流量，因此服务的整体稳定性依赖于Service Mesh
• 在本来具有一定复杂度的分布式系统引入的大量 Service Mesh 服务实例，也会极大地增加运维的复杂性
• 需要的专业知识：在容器编排器(如Kubernetes)之上添加Istio之类的服务网格通常需要运维人员成为这两种技术的专家。
• 平台的依赖性: 服务网格的侵入性迫使开发人员和运维人员适应一个高度自治的平台，并遵守其规则。

微服务架构更强调去中心化、独立自治、跨语言，但是通常微服务框架限制了这一点，不可能为每种语言都实现一种框架，要么都用一种语言，要么实现多种语言的框架。如果在一个小公司，Service Mesh 的优势并不是十分明显，小公司很少会考虑采用多语言，因为多一种语言就意味着要花费额外的精力进行维护，所以到目前为止，大多数公司在后端只使用一两种语言。但是，对于大规模部署微服务，内部服务异构程度高的场景，使用 Service Mesh 方案是一个不错的选择。并且，当我们选择使用 Service Mesh 架构的时候，需要对具体的 Service Mesh 实现方案（例如：Istio）做好充分的技术准备和经验积累工作，方能确保方案的顺利实施，尤其是在实施初期，对Service Mesh的管理和运维会是一个棘手的问题。

五、Serverless：

在微服务与容器技术火热之后，Serverless（无服务器架构）成为新的热点，无服务器云函数可以让用户无需关心服务器的部署运营，只需开发最核心的业务逻辑，即可实现上线运营，具备分布容灾能力，可以依据负载自动扩缩容，并按照实际调用次数与时长计费。使用 Serverless 架构可以免除所有运维性操作，开发人员可以更加专注于核心业务的开发，实现快速上线和迭代，把握业务发展的节奏。Serverless 架构可以认为是对微服务和容器化的一种补充，为用户提供了一种新的选择，来应对复杂多变的需求，尤其适合快速发展的初创型公司。

六、中台：

1、业务中台：

随着业务的扩大，真正体现出了中台服务的价值，做个简单的中台服务优势总结：

• 服务重用：真正体现 SOA 理念的核心价值，松耦合的服务带来业务的复用
• 快速响应：更快的通过共享服务的组合响应新业务
• 降低成本：对于新业务，无需再投入新的重复的开发力量，减少人员成本
• 服务进化：随着新业务的不断接入，共享服务也需从仅提供单薄业务功能，不断的自我进化成更健壮更强大的服务，不断适应各种业务线，真正成为企业宝贵的IT资产
• 效能提升：开发人员更专注某一领域，开发更快，更易维护
• 数据累积：各个业务的数据都沉淀在同一套中台服务，可以不断累积数据，最终发挥大数据威力

而中台服务对于服务端开发人员来说，也更具有挑战性。各业务流量汇聚中台服务，服务是否能扛得住大流量、高并发、高可用，以及为适应不同业务线，中台服务的抽象设计能力也是很大的挑战。

2、数据中台：

数据中台，用一句话定义的话就是共性数据能力下沉和整合，并以数据服务访问层对外提供可复用的能力。是对业务中台核心共享数据的跨域整合，再通过加工后提供整合后的数据服务能力。这里面有两个重点：第一是数据要跨域整合、第二是数据要加工处理后再提供增值服务能力。

数据中台的重点是数据业务化，数据来源于业务又反哺业务，不断的迭代循环，也就是把数据变成资产并服务于业务的机制。

传统BI和数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是数据能力渗透到各个业务环节，而不仅仅局限于决策分析类应用场景。数据中台持续不断的将数据进行资产化，价值化并应用到业务，而且关注数据价值的运营。数据中台和传统BI架构有重合，也有交集，相同的就是都需要整个数据采集集成，数据存储，数据模型构建，数据开发和分析。差异点在于数据中台需要有统一的数据服务能力开放层，提供给业务使用，而弱化了传统BI里面的数据分析和报表展现层。

大数据平台是一个技术平台，这个技术平台提供了对于大数据的分布式采集，存储，流处理和计算，实时分析等能力。在没有大数据平台前也有数据集成和管理的平台，这种平台可以实现对结构化数据本身的采集，集成和管理。因此我们常说的大数据平台可以理解为一个纯粹的数据技术能力平台，里面本身是空的，需要不断的接入新的服务，才能够形成服务目录体系。而任何一个数据中台，底层都需要一个提供数据存储和处理能力支撑的技术平台。

其次，数据中台的范畴包括了如下几个方面：

• 一套底层的数据技术平台（比如大数据平台)
• 一套数据资产（业务层面的内容，实际数据，数据模型，算法）
• 一套数据服务能力提供和共享
• 一套数据管控和治理标准规范体系

3、微服务与中台的区别：

3.1、中台的核心价值可以总结为两点：

（1）第一点就是灵活敏捷支撑业务：

“小前台，大中台”的运营模式，就是美军的“特种部队(小前台) 航母舰群(大中台)”的组织结构方式，以促进管理更加扁平化。十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击。而精准打击的导弹往往是从航母舰群上发射而出，后方会提供强大的侦察火力后勤支援。所以如果中台没有办法承接前线的需求，前线就会不认可它服务的价值。

（2）进一步的资源整合复用，降低成本

“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。前台要做什么业务，需要什么资源可以直接同公共服务部要。

3.2、微服务：

​    微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。

3.3、中台 = SOA思想 + 微服务

• SOA思想：共性可复用业务能力下沉，并提供给前台应用使用
• 微服务思想：共性能力构建时候尽量大拆小，可扩展，松耦合

SOA 所有的理念都是基于现有应用系统展开的，不管是对服务的梳理还是服务之间的交互，都是以现有应用系统为载体的，中台不同于 SOA 之处在于，中台是一种平台化思维，它并不是从系统集成的角度去思考问题，而是从架构层面上重构了整个 IT 生态。

中台无疑是一种更深刻、更底层的变革，它完全破除了应用之间的壁垒，把企业的核心业务能力 “中心化”，把它们提炼并沉淀到中台的各个业务中心上，而不是面向单一业务方向或渠道的应用系统上。这在 SOA 架构下是很难实现的，因为中台的业务中心与 SOA 的服务载体（即应用系统）之间有着本质区别，它们的定位和服务对象都不同，这些区别决定了SOA 依然是一种相对松散的分治式的架构，很难与中台这种更加中心化、更为强力的架构体系相抗衡。

当前互联网企业谈的中台基本就是 SOA 架构思想和微服务两者的一个融合，既体现了共性业务能力下沉，又体现了共性能力要以大拆小的微服务方式构建。如下图：

中台是一个业务层面概念，微服务是一个技术层面概念。中台核心仍然是共性业务能力下沉和复用，只是互联网企业在实现中台架构的时候，将中台技术实现和微服务做了融合。但是企业内业务中台实现，只要满足共性业务能力统一提供给上层使用，即使底层提供能力的仍然是传统遗留业务系统，那么也可以将构建了一个业务服务能力中台。

同时也可以看到微服务仅仅是中台的一个技术实现，你可以在很多非中台场景下采用微服务，小到原来一个业务系统拆分后全新构建这种场景。因此采用了微服务架构离中台实现十万八千里。同时不采用微服务也可以实现中台。

---

相关阅读：

常见的服务器架构入门：从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh

常见分布式理论（CAP、BASE）和一致性协议（Gosssip协议、Raft一致性算法）

一致性哈希算法原理详解

Nacos注册中心的部署与用法详细介绍

Nacos配置中心用法详细介绍

SpringCloud OpenFeign 远程HTTP服务调用用法与原理

什么是RPC？RPC框架dubbo的核心流程

服务容错设计：流量控制、服务熔断、服务降级

sentinel 限流熔断神器详细介绍

Sentinel 规则持久化到 apollo 配置中心

Sentinel-Dashboard 与 apollo 规则的相互同步

Spring Cloud Gateway 服务网关的部署与使用详细介绍

Spring Cloud Gateway 整合 sentinel 实现流控熔断

Spring Cloud Gateway 整合 knife4j 聚合接口文档

常见分布式事务详解（2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知）

分布式事务Seata原理

RocketMQ事务消息原理

---

参考文章：https://blog.csdn.net/weixin_39815879/article/details/110456525

（备注：文章中的图片均来自于互联网，侵删）