微服务架构体系
架构的演进
这种东西有点信雅达，没什么绝对标准
-
单体应用：在第一阶段的单体应用很好理解。
-
垂直应用：接着随着业务量增大, 将应用拆成互不相干的几个应用，Web框架(MVC) 是关键。
-
这一步，前后端分离、使用缓存、数据库和应用服务分离都会做, 但服务间是独立的无法调用，且可能存在重复代码。
-
分布式应用：垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务。这时用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
-
集群、读写分离、反向代理、加速、分布式数据库、nosql、服务拆分都会处理、消息。
-
实现了服务调用，代码复用
其实这时已经能算一种“微服务”了，一般会使用SpringBoot
-
弹性流动计算：服务越来越多，容量评估，资源的使用等问题逐渐显现，需要调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA 面向服务架构) 是关键。
-
这时候要有一个注册中心，调用关系不需要自行维护了。
-
Dubbo 就是SOA的概念了，更关注RPC和服务治理。
-
微服务：最后是通俗含义的微服务，使用 SpringCloud编码，使用Docker、K8S等，解决微服务软运维问题。
-
微服务本身也算是面向服务架构（SOA），它是SOA发展道路上的优化选择，关注的是服务拆分力度，即：如何将服务合理的拆的更细、更小
-
微服务需要关注点又更多，监控、日志、安全、调度、弹性容错等
微服务和SOA
- 微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响，不再需要协调其它服务部署对本服务的影响；
- 微服务提供的接口方式更加通用化，如HTTP RESTful，各种终端都可以调用，无关语言、平台，所以技术可以更随意，只需要提供API
- 微服务更倾向于分布式去中心化的部署方式，数据的去中心化，也可以使用更不同的数据库技术；
- 微服务运维使用docker,k8s 可以自动化部署，集中管理。
| SOA | 微服务 | |
|---|---|---|
| 服务粒度 | 粒度较粗 | 细粒度拆分 |
| 部署难度 | 需要重新创建或者部署整个应用 | 每个微服务可以独立构建部署 |
| 通信开销 | 大部分业务模块在一个应用里面，通信开销低 | 更多的远程调用，增加了通信开销 |
| 存储 | 一般所有服务共享数据存储 | 每个可以拥有单独的存储 |
| 业务易上手 | 需要了解整个应用的业务，上手较难 | 单服务上手容易，但是服务集群理解比较难(复杂度守恒定律：业务复杂度不会因为迁移到了微服务而降低) |
| 通信方式 | SOA体系结构依赖于消息传递（AMQP，MSMQ）和SOAP作为主要的远程访问协议，协议偏重量级； | 使用轻量级协议，如HTTP/REST |
| 可扩展性 | 难以扩展 | 使用容器技术很方便扩展 |
微服务和分布式
分布式关注的是服务分开部署，也就是如何将单一服务部署，变为多服务部署（垂直+水平拆分）。 微服务关注的是服务拆分力度，即：一个服务要拆分到多大的维度合适
Spring Cloud 和 Dubbo
说到微服务，两大框架的讨论肯定跑不了
区别
定位
Dubbo 是 SOA 时代的产物，关注点主要在于服务的调用，流量分发、流量监控和熔断，定位服务治理和** RPC； Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致。 Spirng Cloud 更是一个微服务架构生态。
服务发现
对于服务发现而言，可用性比数据一致性更加重要，AP 胜过 CP，而 Eureka 设计则遵循 AP 原则。
传输方式：
- Dubbo底层用Netty这样的NIO框架，基于TCP协议传输的，配合以Hession序列化完成RPC通信;
- SpringCloud基于Http协议+rest接口调用远程过程的通信，
- 相对来说，Http会有更大的报文，占的带宽也更多。但是REST相比RPC更灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。
模块区别：
Dubbo 主要分为服务注册中心，服务提供者，服务消费者，还有管控中心； SpringCloud则是一个完整的分布式一站式框架，服务注册中心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，消息总线，以及服务追踪等；
架构 SpringCloud
流程：
- 请求统一通过 API 网关（Zuul）来访问内部服务。
- 网关接收到请求后，从注册中心（Eureka）获取可用服务。
- 由 Ribbon 进行均衡负载后，分发到后端具体实例。
- 微服务之间通过 Feign 进行通信处理业务。
- Hystrix 负责处理服务超时熔断。
- Turbine 监控服务间的调用和熔断相关指标。
架构 Dubbo
Spring Cloud 和 K8s
微服务关注什么
差不多一半关注点是和运维相关的。spring cloud只是一个开发框架，对于应用如何部署和调度是无能为力的，而kubernetes是一个运维平台，看起来都不够。 也许用spring cloud+cloud foundry去和kubernetes比较才更加合理，但即使加入了cloud foundry的paas能力，spring cloud仍然是“侵入式”的且语言相关，而kubernetes是“非侵入式”的且语言无关。
区别
spring cloud关注的功能是kubernetes的一个子集。
| 关注点 | Spring Cloud | Kubernetes |
|---|---|---|
| 自愈和自动伸缩 | 无 | kube-controller-manager |
| 调度和发布 | 无 | kube-scheduler+Deployment |
| 配置管理 | Spring Cloud Config/Nacos | ConfigMap |
| 服务发现和LB | Eureka/Nacos | Service+CoreDNS/Istio |
| 弹性和容错 | Hystrix/Resillience4j | Istio |
| API网关 | Zuul/Spring Cloud Gateway | Ingress/Istio Gatewa |
| 服务安全 | Spring Cloud Security | Istio |
| 调用链监控 | Spring Cloud Sleuth+ZipKin | Istio+Jaeger/ZipKin |
| Metrics监控 | actuator+Spring Boot Admin | Istio+Prometheus |
| 日志收集 | Spring Cloud Sleuth+ELK | fluentd/Istio |
两边的解决方案都是比较完整的。 kubernetes，在Istio还没出来以前，只能提供最基础的服务注册、服务发现能力（service只是一个4层的转发代理），istio出来以后，具有了相对完整的微服务能力。 spring cloud，除了发布、调度、自愈这些运维平台的功能，其他的功能也支持的比较全面。 相对而言，云厂商会更喜欢kubernetes的方案，原因就是：非侵入。平台能力与应用层的解耦，使得云厂商可以非常方便的升级、维护基础设施而不需要去关心应用的情况。
Service Mesh
介绍
又译作“服务网格”，作为服务间通信的基础设施层。 可以将它比作是应用程序或微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。 对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
Isito
目前Service Mesh具体落地实现的一种，呼声最高。
| 功能列表 | Spring Cloud | Isito |
|---|---|---|
| 服务注册与发现 | 支持，基于Eureka，consul等组件，提供server，和Client管理 | 支持，基于XDS接口获取服务信息，并依赖“虚拟服务路由表”实现服务发现 |
| 链路监控 | 支持，基于Zikpin或者Pinpoint或者Skywalking实现 | 支持，基于sideCar代理模型，记录网络请求信息实现 |
| API网关 | 支持，基于zuul或者spring-cloud-gateway实现 | 支持，基于Ingress gateway以及egress实现 |
| 熔断器 | 支持，基于Hystrix实现 | 支持，基于声明配置文件，最终转化成路由规则实现 |
| 服务路由 | 支持，基于网关层实现路由转发 | 支持，基于iptables规则实现 |
| 安全策略 | 支持，基于spring-security组件实现，包括认证，鉴权等，支持通信加密 | 支持，基于RBAC的权限模型，依赖Kubernetes实现，同时支持通信加密 |
| 配置中心 | 支持，springcloud-config组件实现 | 不支持 |
| 性能监控 | 支持，基于Spring cloud提供的监控组件收集数据，对接第三方的监控数据存储 | 支持，基于SideCar代理，记录服务调用性能数据，并通过metrics adapter，导入第三方数据监控工具 |
| 日志收集 | 支持，提供client，对接第三方日志系统，例如ELK | 支持，基于SideCar代理，记录日志信息，并通过log adapter，导入第三方日志系统 |
| 工具客户端集成 | 支持，提供消息，总线，部署管道，数据处理等多种工具客户端SDK | 不支持 |
| 分布式事务 | 支持，支持不同的分布式事务模式：JTA，TCC，SAGA等，并且提供实现的SDK框架 | 不支持 |
| 其他 | …… | …… |
从上面表格中可以看到，如果从功能层面考虑，Spring Cloud与Service Mesh在服务治理场景下，有相当大量的重叠功能，从这个层面而言，为Spring Cloud向Service Mesh迁移提供了一种潜在的可能性。
服务网格
服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。
- 代理在服务网格中被称为数据层或数据平面（data plane），
- 管理流程被称为控制层或控制平面（control plane）。 数据层截获不同服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。
更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。
在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。
相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。 总而言之，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。
控制平面 数据平面
控制平面的特点：
- 不直接解析数据包。
- 与控制平面中的代理通信，下发策略和配置。
- 负责网络行为的可视化。
- 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。
数据平面的特点：
- 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的。
- 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
- 对应用来说透明，即可以做到无感知部署。
服务网格带来的变化
第一，微服务治理与业务逻辑的解耦。服务网格把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 sidecar 的模式进行部署。
第二，异构系统的统一治理。不同语言、不同框架的应用和服务，能够统一管控
技术优势
此外，服务网格相对于传统微服务框架，还拥有三大技术优势：
-
可观察性。
-
服务网格是一个专用的基础设施层，所有服务间通信都要通过它，它在技术堆栈中处于独特的位置，以便在服务调用级别上提供统一的遥测指标。这意味着，所有服务都被监控为“黑盒”。
-
服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据。本质上等同于 web 服务器日志可以提供的数据，但是服务网格可以为所有服务捕获这些数据，而不仅仅是单个服务的 web 层。存储与分析这些数据则需要额外能力的机制的补充，然后作用于警报或实例自动伸缩等。
-
流量控制。
-
通过 Service Mesh，可以为服务提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各种控制能力。
-
由于服务网格的设计目的是有效地将来源请求调用连接到其最优目标服务实例，所以这些流量控制特性是“面向目的地的”。这正是服务网格流量控制能力的一大特点。
-
安全。
-
在某种程度上，单体架构应用受其单地址空间的保护。服务网格的安全相关的好处主要体现在以下三个核心领域：服务的认证、服务间通讯的加密、安全相关策略的强制执行。
-
平台独立: Istio 是独立于平台的，旨在运行在各种环境中，包括跨云、内部部署、Kubernetes、Mesos 等。
-
集成和定制: 策略执行组件可以扩展和定制，以便与现有的 ACL、日志、监控、配额、审计等方案集成。
服务网格被称为第二代“微服务架构”。但服务网格也有它的局限性。
- 复杂度。服务网格将 sidecar 代理和其它组件引入到已经很复杂的分布式环境中，会极大地增加整体链路和操作运维的复杂性。
- 运维人员能力。
- 延迟。从链路层面来讲，服务网格是一种侵入性的、复杂的技术，可以为系统调用增加显著的延迟。
- 适配。服务网格的侵入性要适应高度自治的平台并遵守平台的规则。
小结
从架构演进路径来看，从最早期的巨石单体（Monolithic）到分布式（Distributed），再到微服务（Microservices）、容器化（Containerization）、容器编排（Container Orchestration），最后到服务网格（Service Mesh）、无服务器（Serverless）。
K8S 正爆炸式发展，已经成为企业绿地应用的容器编排的首选。如果说 Kubernetes 已经彻底赢得了市场，并且基于 Kubernetes 的应用程序的规模和复杂性持续增加，那么就会有一个临界点，而服务网格则将是有效管理这些应用程序所必需的。
随着服务网格技术的持续发展，其实现产品（如 Istio）的架构与功能的不断优化，服务网格将完全取代传统微服务架构，成为大小企业微服务化和上云改造的首选架构。