背景

传统行业技术架构都已单体系统为主，一般会遇到如下问题：

• 交付速度较慢，创新响应周期长。传统项目模式都是瀑布貌似，需要有一个比较完整的需求，需要开发的功能比较多，许多功能一起设计，一起开发和一起上线，如果遇到 Bug，还需要一起排查一起联调；

• 系统耦合严重，架构治理困难。前端后端在一起，后端所有功能在一份服务里边，开发一些功能很可以要修改一些功能的 Common 包，设计和维护成本太高；

• 高并发场景，支撑能力差。扩展能力较差，大多是有状态服务，无法横向扩容，导致高并发下服务很容易宕机；

• 传统技术架构，上云困难。有些传统服务还在使用 weblogic 等重量级容器，制作镜像非常不变。

传统企业就需要做数字化转型，解耦产品业务架构，建设分布式微服务系统，这就需要建设一个微服务平台来支撑分布式体系下的业务系统。

平台关键技术及架构方案

运行时选型

微服务开源体系：Spring Cloud、Spring Cloud Alibaba、Dubbo

容器技术：Docker、Kubernetes

配置中心：Apollo、ConfigMap

注册中心：Eureka、Zookeeper、Consul、Naocs

自研管理平台：开发路由管理、负载管理、线程池管理、限流管理、熔断降级管理、故障隔离管理和接口治理等功能，提升整个平台的监管控能力。

在微服务开源选择上，比较依赖于阿里系的开源技术，可以选用 Spring Cloud Alibaba 或 Dubbo，如果自己有自研能力可以选在 Spring Cloud，毕竟遇到一些坑的话，Spring Cloud 普及率比较好，如果找到解决方案。配置中心推荐 Apollo，使用阿里技术栈的可以用 Naocs，支持灰度和对环境发布。注册中心的选在要开业务场景，追求数据一致性的可以选在 Zookeeper 等 CP 容灾形式的注册中心，对高可用要就比较高的可以选在 Eureka AP 容灾形式的注册中心。对于准备上云或是已经上云的服务，可以使用 Spring Boot+Kubernetes 自带的负载，最求流量治理灵活性的可以上 Istio+Envoy Service Mesh 技术架构，不过技术复杂度和运维复杂度有上升不少。

监控告警

按照 4 个黄金指标：延迟，流量，错误以及饱和度。使用开源 Prometheus 和 Grafana 进行建设。

流量及速率监控能力

• (请求)速率：节点和接口维度的当前请求数；

• 请求总量：业务系统、服务节点和接口维度当日请求量

• 磁盘流量：读写数据及 IO 利用率

错误请求监控能力

• 接口及节点失败次数及失败率，包括当前和总的失败次数

• 接口失败较高的前 10 个接口

• 系统状态（上线和下线状态）

• 熔断降级监控

延迟及耗时监控能力

• 网关响应时间（最大，平均）

• 微服务与微服务之间响应时间（最大，平均）

饱和度监控能力

• CPU、内存、磁盘基础使用情况

• 接入接出线程池接入：接出线程池， 最大线程， 当前活跃线程， 队列剩余， 队列拒绝

JVM 监控能力

• 堆内存、新生代、老年代

• Eden、Survivor 区和 GC

功能增强

1. POM 封装，将自研的和所用的基础 sdk 封装为一个 dependency 中，方便升级，也方便业务系统使用；

2. 框架引入，只需要添加注解就可以实现：认证授权，配置获取，日志采集，IP 校验，服务熔断，服务限流，Mac 校验，报文加密等功能；

3. 指标监控埋点，使用原生态 Feign 访问，通过 Spring AOP 对调用 Feign 监控功能进行增强，最大限度减少代码侵入性；

4. 支持管理平台配置实时生效，接口超时、IP 校验、服务熔断、服务限流都可以在管理平台实时配置实时生效。

浅谈 Service Mesh 技术

云原生落地三驾马车：Kubernetes、Service Mesh、Serverless，其中 Service Mesh 是云原生落地的关键步骤。Service Mesh（服务网格） 是云原生技术体系下的新型服务架构，是分布式应用在微服务软件架构之上发展起来的新技术，旨在将微服务间的连接、安全、流控和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

Service Mesh 技术优势

Service Mesh 将平台功能下沉到数据平面(SideCar)中，将数据平面作为网络基础设施，实现业务逻辑与非业务逻辑的分离，使应用专注于业务，实现应用轻量化，推进应用云原生化，具体表现为：

• 多语言支持和应用无感升级

• 无侵入提供流量控制、安全、可观察性

• 非业务逻辑功能下沉到基础设施

技术选型

控制平面（Isito），为数据平面提供实施策略，如负载均衡策略、流量路由策略和弹性等。

数据平面（Envoy），处理网络流量的功能组件，如服务发现，负载均衡和灰度发布等。

基于 Istio+Envoy 内部调用逻辑

控制平面中的核心主键包括：Pilot、Citadel 和 Galley，Pilot 是管理和配置数据平面 Sidecar 代理实例的路由流量规则，Citadel 负责安全认证方面，Galley 负责配置验证功能，控制平面和数据平面是通过 Xds 协议进行交互的。后面会详细讲一下如何通过 Gateway、VirtualService、DestinationRule 等流量控制进行通讯的。

参考：

• Gartner 报告中 ServiceMesh 的内部调用逻辑说明