架构训练营 week6 课程总结

• 微服务架构

SOA 和微服务架构的区别是：SOA 有 ESB 这个核心的管道，进行各种协议和语言的转换，而微服务则没有这个 smart pipe，而是用一整套的基础设施来支持微服务的快速交付与问题排查。

单个微服务可以是整洁架构、微内核架构。整个微服务架构是端到端分层架构中的业务层。

• 微服务架构陷阱与挑战

• 陷阱主要有：

• 粒度太细

• 基础设施缺乏

• 挑战主要有

• 数据分布：主要用分布式事务解决，用 BASE 实现最终一致性

• 服务分布：细分为接口兼容和接口循环调用两种问题。接口兼容主要推荐使用接口多版本（即使要复制代码也先复制），而接口逻辑兼容则比较麻烦，不推荐。

• 微服务拆分技巧

拆分方式方面说，有按质量拆分和按业务拆分。而按质量拆分又分为：按性能拆分，按业务重要程度拆分，按可用性拆分，按稳定性拆分这四种。

而使用微服务，需要有基础设施的支撑，而基础设施可以一开始就搭建完整的设施，也可以最开始搭建核心的设施，之后再逐步补充其他设施。

落地方式，则有一步到位和逐步落地。一般新搭建微服务会选择一步到位，而基于老项目改进会选择逐步落地。

• 微服务基础设施选型

微服务架构全貌是分层的，主要有 4 层：服务接入层（服务网关，服务流控，服务降级，服务安全）；服务运行层（服务注册，服务发现，服务路由，服务容器）；技术支持层（接口框架，分布式事务，自动化测试，自动化部署，灰度发布，服务监控等），基础设施层（配置中心，日志中心，分布式锁，消息队列）。

而微服务框架，则有 3 种类型：嵌入式 SDK，反向代理模式，网络代理模式。嵌入式 SDK 比较有代表性的是 Dubbo 和 springcloud，反向代理模式比较有代表性的是 APISIX；网络代理式比较有代表性的是 Istio。

一般嵌入式 SDK 模式比较适合的是单一语言的架构，例如全部用的 java，则可以用嵌入式比较好。否则考虑另外两种模式，支持多语言，而如果需要的服务器数量更多的话，则使用 Istio 的 service mesh 的方式更好。因为反向代理模式的 service proxy 集群，最多适合 1000 台左右的集群。

• 中台深入剖析和实现技巧

说到中台，首先要分清楚中台的两种类型：业务中台和数据中台。

业务中台主要的目的是把多个相似的业务通用能力沉淀到平台，减少重复开发，提升开发效率。

数据中台主要的目的是吧所有业务的数据沉淀到同一平台，支持业务数据打通、复用，避免数据孤岛。提升运营效率。

中台当然不是银弹，也存在问题

1. 中台只会抱大业务的大腿，对于小业务不太感兴趣。

2. 中台边界难以确定，到底哪些是业务做，哪些是中台做，有时候不太好确认。

3. 中台全流程效率不高，需要大量的会议讨论，并且修改中台后，可能会影响到多个业务。

中台落地技巧

1. 使用 pipeline 封装不同的业务流程（使用较多）

2. SPI 封装不同业务