服务网& amp伊斯迪奥
互联网公司经常使用微服务分层架构。
画外音:
为什么服务？有关详细信息，请参见服务解决的问题。
随着数据量和吞吐量越来越大，业务越来越复杂，服务的数量会越来越多，层次会越来越细。除了数据服务层，还会衍生出业务服务层、前端分离等各种层次结构。
画外音:
有关分层的详细信息，请参见互联网分层架构的演进。
不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构自然进化了，微服务架构，潜在的主要矛盾会是什么？
引入微服务架构时，一般会引入一个RPC框架来完成整个RPC调用过程。
如上面粉色部分所示，RPC分为:
画外音:
密不可分的微服务架构，密不可分的RPC细节。
不仅仅是微服务，MQ也是类似的架构:
如上图粉色部分所示，MQ分为:
画外音:
MQ，互联网架构解耦神器。
框架只是第一步，会加入越来越多的RPC和微服务相关的功能。
例如:负载平衡
如果您想要扩展多个负载平衡方案，例如:
RPC-客户端需要升级。
例如:数据收集
如果要采集RPC接口的处理时间来实现统一监控和报警，还需要升级RPC-client。
画外音，处理时间分为:
客户视角处理时间
服务器透视图的处理时间
如果要收集后者，还应该修改和报告RPC-server。
另一个例子:服务发现
服务添加一个实例，并通知配置中心，配置中心通知注册的RPC-client将流量发送到新启动的服务实例，从而快速完成扩展。
另一个例子:呼叫链跟踪
如果要进行完整的链接调用链跟踪，RPC-client和RPC-server都需要升级。以下功能:负载均衡数据收集服务发现调用链跟踪……其实都不是业务功能，所以互联网公司一般都有一个类似于“架构部”的技术部门来开发升级相关功能，而业务线的技术部门则直接使用相关框架、工具、平台来享受各种“黑科技”带来的便利。
完美！！！理想很丰满，但现实很骨感，因为:
经常面临以下问题:
画外音:
兄弟，你们公司推广一个新技术产品需要多久？
有什么办法可以解决这些耦合和这些常见的痛点？
一种想法是将服务分成两个流程，并将它们解耦。
画外音:
许多基础设施，如负载平衡、监控和报警、服务发现和治理、呼叫链等。，都在这一层实现。
这样“业务归业务，技术归技术”，实现完全脱钩。如果所有节点实现解耦，整个架构将演变为:
整个服务集群变成了网格，这就是Service Mesh服务网格的由来。
要说ServiceMesh，就不得不提Istio，这是目前ServiceMesh最流行的做法。今天，我们来谈谈Istio是做什么的。
画外音:你不能落后。
Istio是什么？
Istio是ServiceMesh的产品落地，对它的一些重点描述是:
画外音:
Istio帮助您连接、保护、控制和观察微服务
画外音:
佩服，十条凑在一起很难。事实上，SM可以提供更多的基本服务功能。
画外音:
还在说脱钩。
Istio官网如何吹嘘自己？
画外音:
这个问题的另一种提问方式是“为什么要用Istio？”。
Istio很牛逼。如果要实现ServiceMesh，必须使用Istio，因为:
画外音:
你相信吗？
Istio的核心特点是什么？
Istio强调了它提供的五个关键特性:
画外音:
断路器、超时、重试、高可用性、多路由规则、AB测试、灰度释放、流量百分比分布等。
Istio的吹嘘和特点对于很多通过RESTful提供内网服务的国外公司来说是很有吸引力的，但是和国内的微服务架构相比，未必能达到很好的拉拢效果:
(1)国内的RPC框架基本都是TCP，多协议支持不一定是必须的；
(2)在2)RPC框架中，路由、重试、故障转移、负载均衡、高可用是最基本的；
(3)流量控制、限速和配额管理是服务治理的内容，在微服务架构初期是锦上添花；
(4)自动测量、系统出入口数据采集、通话跟踪、可观察可控后台真的是最吸引人的；
(5)服务对服务的认证。微服务基本是内网接入，只是架构前期的锦上添花；
另一个花边，为什么代理叫sidecar代理？
Istio这么牛逼，它的核心架构是什么？
关于Istio的架构设计，官网用了这句话:
从逻辑上讲，Istio分为:
这两个字是Istio建筑的核心，但也是最容易误导人的地方。
数据平面和控制平面不是由ServiceMesh和Istio首先提出的，它们是计算机网络和消息路由转发中的成熟概念:
画外音:上面两张图片显示了路由器的架构。
其设计原则是:
画外音:
Istio的架构核心与路由器非常相似:
(1)高效转发；
(2)接收并执行来自混合器的策略；
(1)管理和配置边车代理；
(2)实施策略并通过混合器从侧车代理收集数据；
画外音:
(1)sidecar proxy，原文用envoy，后文envoy的意思是代理人；
(2)混音器，不确定怎么翻译。有的文章叫“混音器”，后者直接叫混音器；
(3)pilot，galley，citadel，不敢翻译成pilot，kitchens，forts，以下文字直接用英文；
如体系结构图所示，两层体系结构中有五个核心组件。
特使的核心职责是高效转发。更具体地说，它具有以下功能:
(1)服务发现
(2)负载均衡
(3)安全传输
(4)多协议支持，如HTTP/2和gRPC。
(5)断路器
(6)健康检查
(7)百分比分流路由
(8)故障注入
(9)系统测量
大多数功能都可以在RPC框架中获得，或者相对容易理解。这里主要介绍断路器和故障注入。
它是软件架构设计中的一种服务自我保护或降级的设计思想。
例如，当系统检测到某个接口有大量超时时，断路器策略可以终止对该接口的呼叫(断路器断开)，一段时间后，再次尝试呼叫。如果接口不再超时，它将慢慢恢复呼叫(断路器闭合)。
它是一种在软件架构设计中故意引入故障，以扩大测试覆盖范围，保证系统健壮性的方法。主要用于测试。
国内大部分互联网公司在架构设计上不考虑故障注入，而往往在操作系统内核和路由器的开发调试中使用，可以用来模拟内存分配失败、磁盘IO错误等一些非常棘手的异常，保证测试覆盖率。
Mixer的一些核心能力是:
(1)跨平台，作为其他组件的适配器，实现Istio的跨平台能力；
(2)与特使沟通，实时各种策略。
(3)与特使沟通，收集各种数据。
Mixer的设计核心是“插件”，使Istio能够适应各种复杂的主机环境和后端基础设施。
作为非常重要的控制平面组件，飞行员的核心能力是:
(1)为特使提供服务发现能力；
(2)为Envoy提供各种智能路由管理能力，如A/B测试和灰度发布；
(3)为特使提供各种灵活的管理能力，如超时、重试和断开策略；
Pilot的设计核心是“标准化”，将各种流量控制命令转化为使节可以识别的配置，并在运行时将这些命令传播给所有使节。Pilot将这些功能抽象成一个通用配置的优点是，所有符合这个标准的特使都可以连接到Pilot。
潜台词是，任何第三方只要符合相关API标准，都可以实现自己的代理，都可以和Pilot集成。
Citadel组件，提供最终用户身份验证和服务到服务的访问控制。简而言之，这是一个安全相关的组件。
加里组件是配置获取、验证、处理和分发的组件，采用“解耦”设计，将“从底层平台(如K8S)获取用户配置”与Istio解耦。
Istio采用两层架构和五个模块对微服务ServiceMesh进行解耦:
数据平面，主要负责高效转发
(1)特使模块:代理；；
(2)混合器模块:适配器；支持跨平台和标准化的API
(3)试验模块:控制和配置特使的大部分策略；
(4)citadel模块:安全相关；
(5)厨房模块:与底层平台解耦(如K8S)；
实现与控制分离，经典架构设计方法，懂了吗？
想法比结论更重要。