一、微服务架构详解

1.微服务与 SOA

SOA：面向服务架构

SAP/EMC/Oracle ---- Gartner 咨询

SOA 在传统行业，2B 业务多；微服务在互联网比较多。ESB：enterprise service bus。SAP IBM 做 ESB, 将企业异构服务链接在一起。通常包括：消息路由、格式转换、记录日志、消息传输、异常处理等。

微服务：http 轻量级通讯机制，快速自动化部署。

2.微服务和 SOA 的关系

3.架构演进

4.微服务架构和其他可扩展架构

分层架构

整洁架构

微内核架构

二、微服务架构陷阱与挑战

1.6 大陷阱

a.拆分太细，复杂度增加

b.拆分太细，团队效率下降

c.拆分太细，问题定位困难----全链路追踪

d.拆分过细，系统性能下降-----调用链越长，单次耗时越长。

e.无法快速交付----自动化测试；自动化部署；自动化监控

f.服务管理混乱-----

2.微服务技术挑战

数据分布：

分布式事务

全局幂等

服务分布：

接口兼容

接口循环调用

如果只拆分代码不拆分数据库，不算微服务，因为微服务要可以独立演进。

3.BASE 理论

BASE--Basically Available（基本可用） Soft state（软状态） Eventually consistent(最终一致性)

核心：分布式系统基于 CAP 理论限制，无法作到强一致性，每个应用可以根据自己的业务特点，每个应用都可用用适当的方式来使系统达到最终一致性。

分布式系统，消息，消息队列、接口调用、Zookeeper 事件。

4.本地事务消息

幂等：后台自动处理的，

如果步骤 4 失败，再次 A 发布消息给 B，B 会判断是否已经处理过该消息。

5.消息队列事务消息

6.TCC

蚂蚁金服有使用 RocketMQ 也有 TCC，也有本地事务表。

7.全局幂等

分布式数据通过消息来实现一致性，消息可能会丢失，需要重试，重试就要保证幂等。

任意多次操作和一次操作所产生的影响相同。

全局幂等是保证每个幂等都是全局唯一的。

8.接口兼容和接口循环调用

某个微服务某些接口升级，依赖这些接口的微服务不一定能够全部同时升级---接口多版本；接口逻辑兼容

某业务中，A 调用 B，B 又调用 A，A 处理又进入之前处理逻辑，导致循环调用，整个业务进入死循环。

三、微服务基础设施选型

1.微服务基础设施全貌

2.微服务框架模式

核心：注册、发现和路由。

嵌入式 SDK------例如：spring cloud

反向代理-----apache apisix

网络代理（service mesh)----istio

3.如何选开源微服务框架

四、微服务拆分技巧

1.拆分思路

2.DDD 概要

3.实际项目中的拆分

三个火枪手原则：3 个人左右负责一个微服务，人少风险大，人多细节不清。

4.按质量属性拆分微服务

按性能拆分：例如可以根据流量请求排名，将流量大和强关联的业务拆分到一起。拆分后可以优化大流量的业务，提升性能，降低成本。

按业务重要程度拆分：降低业务相互影响，提升重要业务的高可用性。

按可用性拆分：将经常出问题的业务拆分出来。

按稳定性拆分

五、中台深入剖析和实现技巧

1.什么是中台

将企业的核心能力以数字行式沉淀到平台，

定义：将通用能力进行打包整合，减少重复建设，通过接口行式连接到外部平台，支持业务发展。

业务中台：业务沉淀到同一平台，避免重复开发。

数据中台：所有业务；数据打通；数据复用

2.中台带来的问题

中台和业务边界难以划分

中台全流程效率不高

3.中台落地技巧

微服务搭建中台

pipeline 封装不同业务

spi 封装不同业务

六、手游平台微服务实战

1.交易类型

2.改造过程

3.拆分方式

按重要性拆分

按稳定性拆分

按业务领域拆分

4.手游交易中台