一、引言
1.1 微服务的目的
以拆分和服务化为基础，将海量用户产生的大规模的访问流量进行分解，采用分而治之的方法，达成用户需要的功能指标，并同时满足用户对高可用、高性能、可伸缩、可扩展和安全性的非功能质量的要求。
1.2 微服务的核心要点
业务的功能划分：每个单一的业务功能叫做一个服务，每个服务对应一个独立的职能团队。
去中心化治理：微服务倡导去中心化的治理，不推荐每个微服务都使用相同的标准和技术来开发和使用服务。
交互模式：在微服务领域，微服务之间的交互通过定义良好的接口来实现，不允许使用共享数据来实现。通常使用RESTful样式的API或者透明的RPC调用。
组合依赖：根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。
容错模式：
熔断
当服务的输入负载迅速增加时，如果没有有效的措施对负载进行熔断，则会使服务迅速被压垮，服务被压垮会导致依赖的服务都被压垮，出现雪崩效应，因此，可通过模拟家庭的电路保险开关，在微服务架构中实现熔断。
限流
针对服务突然上量，我们必须有限流机制，限流机制一般会控制访问的并发量，例如每秒允许处理的并发数及查询量、请求量等，实现方式如计数器，令牌桶等。
拆分粒度：
按照微服务的初衷，服务要按照业务的功能进行拆分，知道每个服务的功能和职责单一，甚至不可再拆分为止，以至于每个服务都能独立部署，扩容和缩荣方便，能够有效地提高利用率。拆的越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线。
1.3 微服务的优点与缺点
优点
- 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求；
- 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成；
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
- 微服务允许你利用融合最新技术；
- 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
缺点
- 微服务架构可能带来过多的操作；
- 需要DevOps技巧；
- 可能双倍的努力；
- 分布式系统可能复杂难以管理；
- 因为分布部署跟踪问题难；
- 当服务数量增加，管理复杂性增加。
下文将介绍下几种微服务架构的情况。
二、Spring Cloud
2.1 整体架构
模块交互流程图
2.2 核心组件
2.3 特点
1️⃣ Spring Cloud利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发，组件支持丰富，功能齐全，为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等。它们都可以用SpringBoot的开发风格做到一键启动和部署；
2️⃣ 使用 HTTP 协议的 REST API，服务提供方和服务消费方通过 Json 数据格式交互，只需要定义好相关 Json 字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵；
3️⃣ 性能上因为是HTTP短连接，系统并发量和响应时间不及RPC长连接方式（如Dubbo，相差三倍左右），在报文比较小，响应时间要求严格的场景不太适合；
4️⃣使用spring boot admin作为服务基本情况监控，原理是Spring Boot Actuator组件；
5️⃣ 部分组件的功能及稳定性并未达到生产级别，使用者不多，需要引入其他功能相似组件。
三、Dubbo
Dubbo是一个分布式、高性能、透明化的RPC服务框架，提供服务自动注册、自动发现等高效及多样性服务治理方案，可以和Spring框架无缝集成。
3.1 整体架构
- Provider：暴露服务的服务提供方；
- Consumer：调用远程服务的服务消费方，使用软负载均衡算法；
- Registry：服务注册与发现的注册中心，如Zookeeper、Redis等；
- Monitor：统计服务的调用次数和调用时间的监控中心，服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心；
- Container：服务运行容器；
Dubbo分层结构设计图
- config配置层
对外配置接口，以ServiceConfig, ReferenceConfig为中心，可以直接初始化配置类，也可以通过spring解析配置生成配置类；
- proxy服务代理层
封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么像调本地服务一样调远程服务；
- registry注册中心层
封装服务地址的注册与发现，以服务URL为中心，扩展接口为 RegistryFactory, Registry, RegistryService；
- cluster路由层
封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为 Cluster, Directory, Router, LoadBalance；
- monitor监控层
RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为 MonitorFactory, Monitor, MonitorService；
- protocol远程调用层
封装RPC调用，以Invocation, Result 为中心，扩展接口为Protocol, Invoker, Exporter，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的流程中实现Filter拦截点；
- exchange信息交换层
封装请求响应模式，同步转异步，以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer；
- transport网络传输层
抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec；
- serialize数据序列化层
可复用的一些工具，扩展接口为Serialization, ObjectInput, ObjectOutput, ThreadPool。
3.2 核心组件
Spring Cloud与Dubbo功能对比
3.3 特点
四、Spring Cloud Alibaba
4.1 整体架构
类似Spring cloud的架构，适配集成Alibaba的多种中间件，注册中心换成了Nacos，限流熔断从Hystrix换成了Sentinel，服务间调用可以使用Dubbo，使用RocketMQ作为消息总线及事件驱动组件，用Seata组件（前身是fescar）支持分布式事务功能，目前最新版本是2.1.0.RELEASE。
4.2 核心组件与特点
Nacos基本架构
Sentinel 的主要特性
Sentinel 的开源生态
与spring cloud相关组件对比
几种服务治理组件对比
使用demo：https://www.jianshu.com/p/9a8d94c0c90c。
五、Service mes
5.1 整体架构
如下是简化的Service Mesh架构，服务A和服务B相互调用，不再是以前通过微服务框架直接指向的方式，而是在中间加了两个叫做Sidecar（边车）的东西，各种服务都在这里处理数据上的逻辑。Sidecar的作用是数据面的代理，贴近数据并受控于控制面。
基本架构图
实际业务中，尤其是中台架构下，企业往往需要很多的微服务，即服务A、服务B相互调用情形不断扩展，逐渐形成更多的服务加Sidecar的组合，就变成了一个真正意义的Service Mesh。
服务的网格化（mesh）
5.2 核心组件
Istio架构图
主流云原生Service Mesh框架是Istio，Go语言实现，与容器编排系统Kubernetes一脉相承，下面介绍其主要组件，目前Istio版本为1.3.x release：
5.3 特点
1、Service Mesh所带来的核心价值可以总结为：
- 基础设施下沉 —— 微服务架构支撑、网络通信、治理等相关能力下沉到基础设施层，业务部门无需投入专人开发与维护，可以有效降低微服务架构下研发与维护成本；
- 降低升级成本 —— Sidecar支持热升级，降低中间件和技术框架客户端、SDK升级成本；
- 语言无关 —— 提供多语言服务治理能力；
- 降低复杂测试、演练成本 —— 降低全链路压测、故障演练成本和业务侵入性。
2、数据面以Envoy Proxy作为代理组件。通过Outbound流量拦截或显示指向Envoy Proxy地址的方式代理发起请求流量，经过Envoy Proxy的服务发现、负载均衡、路由等数据面逻辑后，选择目标服务实例地址进行流量转发；在Inbound流量接收端进行流量拦截（可配置是否拦截），对Inbound流量进行处理后转发至目标服务实例。
3、控制面以Pilot为核心组件。通过建立与Envoy Proxy双向GRPC连接，实现服务注册信息、服务治理策略的实时下发与同步。其他控制面组件Mixer（策略检查、监控、日志审计等）、Citadel（认证与授权）、Galley（配置检查）可在实际场景中配置关闭。
4、平台开放与扩展主要通过Kubernetes CRD与Mesh Configuration Protocol（简称为MCP，一套标准GRPC协议）。平台默认支持Kubernetes基于ETCD的注册中心机制，可通过MCP机制对接更多诸如Consul、Eureka、ZooKeeper等多注册中心；对服务治理策略的配置可通过定义Kubernetes CRD或实现MCP GRPC服务对接实现。
5、高可用设计主要基于Kubernetes及Istio机制实现。数据面Envoy Proxy以Init-Container方式与业务Container同时启动，Istio提供了Pilot-agent组件实现对Envoy Proxy生命周期、升级的支持，保证Envoy Proxy的高可用。控制面所有Istio组件均由Kubernetes多副本探针机制保证高可用性。Istio目前支持服务部署于Kubernetes、使用Consul注册服务、服务运行于单个虚拟机上集成，自定义 Istio的策略执行组件可以扩展和定制，以及与acl、日志记录、监视、配额、审核等现有解决方案集成。
6、Alibaba的对Istio架构的改造落地实践：https://zhuanlan.zhihu.com/p/96720618。
实践方案中放弃Istio 通过 iptables 的 NAT 表去做流量透明拦截的方式（NAT 表所使用到的 nf_contrack 内核模块效率很低），自研全新的透明拦截组件mangle；也没有采用 Istio 中的 Mixer 组件，用内部广泛使用的 Sentinel 组件替代，每个请求都会经过 Sentinel Filter 做处理。限流所需的配置信息则是通过 Pilot 从 Nacos 中获取，并通过 xDS 协议下发到 Envoy 中，实践中Service Mesh 的引入对于 RT 的影响和带来的 CPU 开销是基本一样的，而内存开销则因为依赖服务和集群规模的不同而有相当大的差异，Envoy 在内存的使用上仍存在很大的优化空间。
7、Service Mesh 离普及还面临一定挑战：
（1）性能尚存问题，服务间调用因为两层Sidecar，请求链路多两跳；Istio Mixer集中式后端成为性能瓶颈；
（2）Istio架构复杂，一定的技术门槛，掌握和实施成本较高，稳定性及产品化应用有待验证；
（3）真实落地的产品和企业还是比较少，提供的经验比较欠缺。
六、Service Comb
2018年10月24日， Apache软件基金会宣布Apache ServiceComb 毕业成为Apache顶级项目。Apache ServiceComb已在数十家企业中使用，包括奇蛙智能科技、华为云、软通动力，传智播客、梅斯医学、文思海辉、中国人保和同济大学等。
6.1 整体架构
6.2 核心组件
6.3 特点
1、异步内核：基于VertX的同步和异步模型编程有效确保了无论是在传统企业或电商领域，还是在新兴的互联网或物联网等新兴企业中，都能够保持高性能和低延迟，以避免在达到峰值负载时应用出现雪崩效应；
2、ServiceComb支持多种通信协议, Rest、Highway（RPC）等，相比SpringCloud的Rest协议，Highway（RPC）协议性能更高，Highway是基于二进制的序列化方式传输数据，采用二进制编码的系统的性能远高于采用文本的HTTP协议；
3、开箱即用体验，开发简单，开发人员通过脚手架网站start.servicecomb.io启动的微服务项目，可以集服务注册、发现、通信和微服务治理能力和默认的集中化配置为一体；
4、ServiceComb的商业版本CSE相比SpringCloud不仅提供了微服务开发框架，还提供了微服务云部署，管理、治理等一站式解决方案；
5、OpenAPI自动代码生成，业务逻辑代码和治理能力隔离，可以使能DevOps Pipeline， 使用契约文件和OpenAPI的双向生成能力可以使不同的团队高效且独立的开发和管理代码、测试和进行文档化工作；
6、官网上的文档资料比较简略，网上可借鉴的实现案例不多，demo：https://blog.csdn.net/zengdongwen/article/details/93486257。
