SOA、ESB、微服务、分布式概念及专业名词阐述_soa esb

SOA、ESB、微服务概念

1 SOA 面向服务

SOA全称：Service Oriented Architecture，面向服务框架。它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完成的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。架构图如下：

2 ESB 企业服务总线

ESB：Enterprise Service Bus，企业服务总线。简单来说，ESB就是一根管道，用来连接各个服务节点。【总线型结构】，ESB的存在就是为了集成基于不同协议的不同服务，ESB做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通；

随着业务越来越复杂，服务越来越多，SOA架构下，它们的调用会变成如下形式：

很显然，这不是我们希望看到的，如果这个时候引入ESB的概念，项目调用就会很清晰。如下图：

3 SOA架构需要解决的核心问题

• 系统间的集成【有序】：我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的就是为了让原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星型结构。这步的实现需要引入一些概念和一些规范，如：ESB、技术规范、服务管理规范。
• 系统的服务化【复用】：我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的就是要把原先固有的业务功能抽象设计成通用的业务服务、实现业务逻辑的快速复用；
• 业务的服务化【高效】：我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提供企业的对外服务能力。'前面两点都是从技术层面来解决系统调用、系统功能复用的问题’本步骤，则是以业务驱动把一个业务单元封装成一项服务。解决高效问题。

4 微服务架构

微服务：Microservices，微服务与SOA架构非常类似，总的来说，微服务就是SOA的进化，它的升级版，只不过微服务架构强调的是"业务需要彻底的组件化和服务化"。原来的业务系统会被拆分成多个可以独立开发、设计、部署运行的小应用。这些小应用通过服务化完成交互和集成。组件表示的就是一个可以独立更换和升级的单元，就要PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。如果我们把PC中的各个组件以服务的方式构建，那么这台PC只需要维护主板（可以理解为ESB）和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如PC需要调用CPU做计算处理，只需要知道CPU这个组件的地址就可以了。

例如：在一个网约车项目中，就可以拆分为地图服务（service-map）、计价服务（service-price）、用户接口（api-boss）、乘客接口（api-passenger）、验证码服务（service-vertificationnode）等

4.1 微服务特征

1. 通过服务实现组件化【乐高积木，玩具合体】
2. 按业务能力来划分服务和开发团队
3. 去中心化
4. 基础设施自动化（devops、自动化部署）

4.2 拓展 DevOps

4.2.1 定义

DevOps与敏捷软件开发是互补关系，DevOps的许多方面来自于敏捷方法论。（DevOps是为敏捷开发服务的）

DevOps(Development和Operations的组合词)是一种重视"软件开发人员（Dev）"和"IT运维技术人员（Ops）"之间的沟通合作的文化、运行或管理。通过自动化"软件交付"和"架构变更"的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。【通俗而言，就是指开发与运维合作更密切，软件开发更频繁、更敏捷】

DevOps包含三大原则：
1.流动原则：加速从开发、运维到交付给客户的流程
2.反馈原则：建设安全可靠的工作体系
3.持续学习与实验原则：采用科学的工作方式，将对组织的改进和创新作为工作的一部分

4.2.2 DevOps实际落地

1.设计组织结构：团队独立运作，互相解耦
2.运维融入项目开发工作
3.流动的技术实践

• 运行部署流水线的基础:自动化环境（Shell、IaC、Docker、K8S、OpenShift）
• 实现快速可靠的自动化测试：Jenkins、TFS、TeamCity、GitLab CI
• 代码持续集成：Git

4.反馈的技术实践

• 建立遥测系统：Tracing（跟踪）、Metrics（指标）、Logging（日志）
• 智能告警：Prometheus、Grafana
• 应用反馈实现安全部署：为团队分配SRE（Site Reliability Engineer）人员，SRE可以理解为软件开发工程师负责了运维工作
• 应用A/B测试【让用户去选择】

所谓A、B测试就是在正式版本上线前，将用户流量对应分成几组，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，进行数据效果的校验。
应用场景：UI优化、文案变化、页面布局、算法优化

• 建立评审和协作流程

5.持续学习与实验的技术实践

• 将学习融入日常工作
• 将局部经验转换为全局改进
• 预留组织学习和改进的时间

详细内容见:https://juejin.cn/post/6965860856311578637

4.3 拓展专业名词（PoC、Prototype、MVP）

PoC：Proof of Concept，概念验证
Prototype：原型
MVP：Minimum Viable Product ，最低可行产品
以上三个概念所要回答的问题：

1.PoC：商业想法在技术上是否可行？
2.Prototype：产品外观如何，怎么运作？
3.MVP：产品是否适合市场并满足潜在用户的需求？
1
2
3

4.2 SOA与微服务架构差别

微服务不强调传统SOA架构里面看重的ESB企业服务总线。同时以SOA的思想进入到单个业务系统内部，实现真正的组件化。（被拆分的模块，每个都可以独立完成一个服务）

Docker容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以通过类似SpringBoot或者Node等技术独立运行。

SOA注重的是系统集成，而微服务关注的是完全分离。（解耦）

5 服务网格（Service Mesh）

5.1 概念

服务网格：Service Mesh，作为服务间通信的基础设施层在系统中存在。我们可以将Service Mesh比作是**应用程序或微服务间的TCP/IP，负责服务间的网络调用、熔断、限流和监控。**我们都知道在编写应用程序时，我们开发人员一般无需TCP/IP这一层（比如提供HTTP协议的Restful应用），同样如果使用服务网格我们也就不需要关心服务间的那些原来是由应用程序或者其他框架实现的事情（熔断、限流、监控等），只需要交给Service Mesh就可以了。

5.2 与微服务区别及特征

微服务与服务网格的区别：微服务更注重服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和DevOps更好的结合等。

服务网格特征：
1.应用程序间通讯的中间层
2.轻量级网络代理
3.应用程序无感知
4.解耦应用程序的重试/超时、监控、追踪和服务发现

6 分布式概念

6.1 一致性问题

在我们的日常开发中，如果遇到数据库读写分离的场景，最头疼的就是数据不一致问题。假设客户端A将系统中的一个值V由V1变为V2，但客户端B无法立即读取到V的最新值，需要在一段时间之后才能读取到。（因为数据库复制之间是存在延迟的）

就目前来说，无法找到一个既能满足数据一致性，又不影响系统性能的方案。【如果保证一致性，就是当用户访问时，必须要等到数据库同步完之后才响应，但是这样就是影响了系统的性能；反之亦然】于是有了一致性级别：

1. 强一致性：保证数据正确，但是影响系统性能
2. 弱一致性：这种一致性级别约束了系统在写入成功后，不保证立即可以读到写入的值，也不保证多久之后数据能够达到一致，但会尽可能的保证到某个时间级别（如秒级别）之后，数据能够达到一致状态。

弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。但经过"不一致时间窗口"这段时间后，后续对该数据的读取都是更新后的值。
存在问题：
一个业务操作先操作了一个服务然后再操作另外一个服务，但是在操作第二个服务的时候出错了，那我的第一个服务该怎么回滚，或者说我的业务该怎么回滚，这就是弱一致性比较难的地方，如果要考虑数据回滚、重试等等这些机制的话，那么这个分布式系统就会比较复杂

4. 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定的时间内，能够达到数据一致的状态。

最终一致性：弱一致性的特殊形式，存储系统保证在没有新的更新条件下，最终所有的访问都是最后更新的值。
规避通常弱一致性存在的问题：
在弱一致性的基础上先允许出错，但是我可以通过一些重试机制或者定时任务去扫描然后针对这种出错的情况直接进行取消，甚至通过人工干预的方式让这些数据达到最终一致性
最终一致性其实很容易就能想到，因为它不需要考虑很多的数据回滚，它的实现相对就会比较容易，而它的性能就会比较好，因为我们不需要考虑它的一致性或同步性等一些操作，而且开发维护的成本也比较低
所以现在的分布式系统中大部分使用就是通过最终一致性的方式去实现分布式事务

6.2 CAP理论

C（Consistency）：一致性
A（Availability）：可用性
P（Partition tolerance）:分区容错性
CAP理论也被称为"帽子理论"，一致性（C）、可用性（A）、分区容错性（P）三者无法在分布式系统中被同时满足，并且最多只能满足其中的两个。

• 一致性：所有节点上的数据时刻保持同步
• 可用性：每个请求都能接收一个响应，无论响应成功或失败
• 分区容错：系统应该持续提供服务，即使系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些server与集群中的其他机器失去联系。

CAP并不是一个普适性的原理，它仅仅适用于原子读写的NoSql场景中，并不适用于数据库系统。

6.3 BASE理论

从前面的分析中我们可以得出：在分布式（数据库分片或分库存在的多个实例）前提下，CAP理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么高可用方案都是徒劳的，因为数据发生了无法修正的错误）。此外XA事务虽然保证了数据库在分布式系统下的ACID（原子性、一致性、隔离性、持久性）特性，但同时也带来了一些性能方面的代价，对于并发和响应时间要求都比较高的电商平台来说，是很难接受的。

eBay尝试了另外一条完全不同的路，放宽了数据库事务的ACID要求，提供了一套名为BASE的新准则。BASE全称为：Basically Available， Soft-state， Eventually Consistent。系统基本可用、软状态、数据最终一致性。相对于CAP来说，它大大降低了我们对系统的要去。

6.3.1Basically Available（基本可用）

表示在分布式系统出现不可预知的故障时，允许瞬时部分可用性

1. 比如我们在淘宝上搜索商品，正常情况下是在0.5s内返回查询结果，但是由于后端的系统故障导致查询响应时间变成了2s
2. 再比如数据库采用分片模式，100W个用户数据分在5个数据库实例上，如果破坏了一个实例，那么可用性还有80%，也就是80%的用户都可以登录，系统仍然可用
3. 电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

6.3.2 Soft-state（软状态）

表示系统中的数据存在中间状态，并且这个中间状态的存在不会影响系统的整体可用性，也就是表示系统允许在不同的节点的数据副本之间进行数据同步过程中存在延时；比如订单状态，有一个待支付、支付中、支付成功、支付失败，那么支付中就是一个中间状态，这个中间状态在支付成功以后，在支付表中的状态同步给订单状态之前，中间会存在一个时间内的不一致。

6.3.3 Eventually consistent（数据的最终一致性）

表示的是所有数据副本在一段时间的同步后最终都能到达一个一致的状态，因此最终一致性的本质是要保证数据最终达到一致，而不需要实时保证系统数据的强一致

BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

7 分布式架构下的高可用设计

7.1 避免单点故障

1.负载均衡技术（failover故障转移/选址/硬件负载F5/软件负载Nginx/去中心化的软件负载(gossip(redis-cluster))）
2.热备（linux HA）high availability
3.多机房（同城灾备、异地灾备）

7.2 应用的高可用性

1.故障监控（系统监控机（cpu、内存）/ 链路控制 / 日志监控）自动预警
2.应用的容错设计、（服务降级、限流）自我保护能力
3.数据量（数据分片、读写分离）

7.3 分布式架构下的可伸缩性

1.垂直伸缩
2.提升硬件能力
3.水平伸缩
4.增加服务器

7.4 加速静态内容访问速度的CDN

7.4.1 CDN概念及作用

CDN：Content Delivery Network，中文释义是内容分发网络。CDN作用：把用户需要的内容分发到离用户最近的地方响应，这样用户能够快速获取所需要的内容。【有连锁店，用户想要点外卖，就让离用户最近的店给用户准备食物】CDN本质就是一种网络缓存技术，能够把一些相对稳定的资源放到距离最终用户较劲的地方，一方面可以节省整个广域网的带宽消耗，另一方面也可以提升用户的访问速度、改善用户体验。现实系统中我们一般会把静态的文件（图片、脚本、静态页面等）放到CDN中。

7.4.2 CDN执行流程

1. 当用户访问网站页面上的内容URL，经过本地DNS系统解析，DNS系统最终会将域名的解析权交给CNAME指向的CDN专用DNS服务器。
2. CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回给用户
3. 用户向CDN的全局负载均衡设备发起内容URL访问请求。
4. CDN全局负载均衡设备根据用户IP地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求。
5. 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务。

选择的依据：根据用户IP地址，判断哪一台服务器距离用户最近。根据用户请求的URL中携带的内容名称，判断哪一台服务器上有yoghurt所需内容；查询各个服务器当前的负载情况，判断哪一台服务器上有服务能力。基于以上条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址。【谁能提供服务，谁的压力小】

6. 全局负载均衡设备把服务器的IP地址返回给用户
   用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容返回到用户终端。如果这台缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向他的上一级缓存服务器请求内容，直到追溯到包含该内容的源服务器并将内容拉到本地。

拓展专业名词（CNAME、DMZ、软件版本发布）

CNAME：

A记录是将域名解析成IP，CNAME是将域名解析成另外一个域名。

A记录：
A记录，即Address记录，他并不是一个IP或者一个域名，我们理解为是一个指向关系：
|域名：www.baidu.com -> 1.1.1.1
|主机名DD	->	2.2.2.2
也就是说当我们访问这些域名或者主机的时候，DNS服务器上会通过A记录帮我们解析出相应的IP地
址以达到后续访问的目的。所以A记录是IP解析，直接将域名或主机名指向某个IP

CNAME：也叫别名记录，相当于给A记录中的域名起个小名儿，比如www.xx.com的小名就
叫www.yy.com好了，然后CNAME记录也和A记录一样，是一种指向关系，把小名
儿www.yy.com指向了www.xx.com，然后通过A记录，www.xx.com又指向了对应的IP：
|www.yy.com -> www.xx.com -> 1.1.1.1
这样一来就能通过它的小名直接访问1.1.1.1了
有人会问，这样不就多了一步了吗？实则不然，比如：
www.yy.com → www.xx.com → 1.1.1.1
www.cc.com → www.xx.com → 1.1.1.1
www.kk.com → www.xx.com → 1.1.1.1
突然服务器的IP地址因为一些不可描述的原因要更换了，改为2.2.2.2了，这时候我们只需要
把www.xx.com -> 2.2.2.2即可，如果不走CNAME的话，就需要更改每一个指向关系
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

原文链接：https://zhuanlan.zhihu.com/p/400556541

DMZ：

DMZ:demilitarized zone，隔离区。是为了解决安装防火墙后外部网络的访问用户不能访问内部
网络服务器的问题而设立的一个非安全系统与安全系统之间的缓冲区。该缓冲区位于企业内部网络
和外部网络之间的小网络区域内。在这个小网络区域内可以设置一些必须公开的服务器设施，比如
企业Web服务器、FTP服务器（File Transfer Protocol Server文件存储和访问）和论坛等。
另一方面，通过这样一个DMZ区，更有效的保护了内部网络，因为这种网络部署，比起一般的防火墙
案，对来自外网的攻击者来说又多了一道关卡。
1
2
3
4
5
6

软件版本发布：

• α版：此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件bug较多，普通用户不建议安装。
• β（beta）版：该版本相对α版已经有了很大的改进，消除了严重的错误，但是还是可能存在一些缺陷，需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者再进行有针对性的修改。该版本也不适合于用户安装。
• γ版：该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户等不及了，可以提前安装试一试
• trial（试用版）：该版本软件通常都有时间限制，过期之后如果用户希望继续使用，一般得交纳一定费用进行注册或购买。有些试用版软件会在功能上做一定的限制。
• unregistered（未注册版）：与试用版类似，只是没有时间限制
• demo版:演示版：在非正式软件版本中，该版本知名度最大，类似于unregistered，只不过demo版一般不能通过升级或注册的方法变为正式版。

总的来说，α、beta、γ可以称为测试版，trial、unregistered、demo称为演示版

7.4.3 什么情况下用CDN？

最适合的是那些不会经常变化的内容，比如图片，js文件、CSS文件，图片文件包括程序模板中CSS文件中用到的背景图片，还有作为网站内容组成部分的那些图片等等。

7.4.4 灰度发布

在企业开发中，我们的应用即使经过了测试部门的测试，也仍然很难全面覆盖用户的使用场景，为了保证万无一失，我们在进行发布的时候一般会采用灰度发布，也就是会对新应用进行分批发布，逐步扩大新应用在整个集群中的比例直到最后全部完成。灰度发布是说针对新应用在用户体验方面完全无感知。【温水煮青蛙】

灰度发布系统的作用在于，可以根据自己的配置，来将用户的流量导到新上线的系统上，来快速验证新的功能，而一旦出问题，也可以马上的进行回滚发布。简单来说就是一套A/B Test系统。

原文链接:
https://mp.weixin.qq.com/s?__biz=MzkyNTI5NTQ1NQ==&mid=2247499596&idx=1&sn=42744e9b34aacc96d53737b82582ae87&source=41#wechat_redirect