【总结】企业级案例驱动 打造高可用、高并发、多 IDC 部署业务中台微服务架构

企业级微服务架构的实践理论

focus on service（架构设计）普适(金融、互联网等各行业)

架构师分类：

NX 复杂事情搞成简单的，简单的事情搞成没有了;千万别炫技

SB 简单事情，搞复杂，复杂事情搞不定

业务拆分方案(数据库的拆分类似)

功能水平拆分->分表

业务垂直拆分->分库

API粒度拆分->读写拆分为单独的服务,互联网行业服务偏重读，但是特殊的场景写很重要，比如用户的注册，一旦用户注册失败，肯定不会再来，需要将读服务、写服务拆分；

读写服务拆分后，如何解决主从库之间的延时问题呢？用户注册成功了，但是执行登录在从库查不到记录，

解决方案1 按照用户ID将用户分库，分库后所有的读可以直接读主库

解决方案2 数据量不大的情况下，可以设置主从之间强同步，而不采用半同步方式

解决方案3 引入redis，通过分布式事务来保证写数据库与redis的一致性，读操作从redis获取，或者从库读不到，强制读主库等将简单问题复杂化->SB

用户执行了一个修改操作，修改登录的用户名这个时候读操作如何做呢？

此时的读操作是无法辨识读到的数据是否最新的，如何解决呢？从业务和技术两个维度来搞，从业务来说判定是否允许一定的延时，如果允许那么就是用户读的是一个旧数据，多刷几次肯定能读到新数据；要么就采用上述的方案2



网关层做了什么事情？

1、请求鉴权

2、协议转化 将http协议转化为二进制，企业内部传递采用http性能是有问题的，企业内部采用tcp协议

3、路由转发

4、通用参数检查 定长部分参数，验证参数的完整性，不会验证参数的语义



数据访问层->屏蔽底层存储的差异性

1、CRUD

2、ORM

3、Sharding 难度大

4、其他



同步架构OR异步架构

一种架构模式不可能通吃，所以不可能只存在一种模式

同步架构

异步架构

目标：提升吞吐量

在那一层做解耦呢？网关层与业务逻辑层加入MQ(任何两层之间加入一层都可以变为异步，比如加入MQ，但是上游和MQ之间是同步，下游和MQ之间是同步，整个链路的耗时会增加，MQ写是顺序写，性能比较高)，为何不增加在APP与网关层之间呢，当然因为网关层可以帮我们过滤掉一部分无用的请求

适用场景

请求类型

读请求 异步不是OK

写请求 写请求按照场景可以做异步，CP或者AP模式下需要注意，比如招商银行转账采用异步方式转账完成，通过一个提示转成在进行完成后会push信息，这个方案在很多场景都在采用

业务类型

金融

社交SNS

总结

常用方法 拆、合

服务调用是从上往下，不会出现同一层级之间的循环依赖

场景balance设计思维模型

CAP架构设计思维模型

掌握哲学本质架构设计思维模型(从北京到上海 座高铁或者火车效果是不一样的)



企业级微服务架构分布式事务设计与实践（架构设计）

focus on data

分布式事务解决方案

1.将分布式事务变成多个本地事务

2.协调多个本地事务

分布式事务模型

CP模型

XA模型：基本实现两阶段提交、三阶段提交 吞吐量上不去，由于存在全局锁

AP模型->互联网常用

同步场景 saga模型 seate是一个解决方案，既支持CP也支持AP。

异步场景 A->DB1 A操作产生消息到MQ，B、C订阅MQ消息，执行对应的操作，B->DB2,C->DB3 引入本地事务消息表，A操作时将写本地事务与写本地事务消息表放在同一个事务中，执行完成后本地事务消息表的msgid放入事务操作队列中(内存队列，重启会丢失)，

1.发送端消息不幂等 at least once

2.消费端处理消息幂等，分布式锁或者消息去重表等

3.A->B-C A、B成功，C失败，如何处理？人工智能：记录错误日志，报警人工介入

4.优点 业务侵入小

Q&A MQ下游的消费服务如何保证事务的成功处理？





企业微服务架构跨国际化多IDC部署设计与实践（运维&部署）

focus on deploy

OP SRE DevOps AiOps NoOps

百度空间 (space uid spaceid spaceurl)/微信朋友圈/微博

用户跨国际注册

国内

服务如何部署？ 服务无状态化stateless

数据如何部署？ 数据有状态statefull

数据如何同步？ 一个主机房，一个从机房；写入经过LVS-Nginx层全部打到主机房进行写，MySQL、Redis等通过机房间的专用线路进行同步；多主引擎比如Pika没有同步机制的服务如何搞呢？先将数据写入MQ(主从)，Pika从主机房或者从机房的MQ进行消费；主机房的MySQL会配置多个从，防止挂掉，如果挂了从机房需要监控新主节点，MHA

CP、AP两种模式数据同步不一样，同步方式 多主引擎户出现数据不一致，可以强制读主，但是RT会增加

常识：每一千公里ping的延迟在20ms





国外

多活，饿了么国内多活，详见知乎饿了么专区

服务如何部署？ 服务无状态化stateless

数据如何部署？ 数据有状态statefull

数据如何同步？ 如何解决冲突？定义偏序关系，push信息给用户(产品侧包容)；update、delete是否存在偏序关系呢？



企业级业务中台微服务架构实践方法论

中台模式

中台的起源

芬兰移动游戏公司Supercell以小前台方式组织开发团队

如何构建中台？

业务中台、技术中台、算法中台、数据中台，

通用能力/功能下沉为公共服务

服务之间的连接如何解决？一键接入

如何落地中台？

架构选择可以是微服务架构、ServiceMesh、SOA、CloudNative、单体架构等；需要组织架构、业务架构、技术架构全面支持；

新增业务一键接入众多业务中台系统

业务注册中心、业务配置中心、业务分发中心



业务中台数据存储如何支持多业务接入，场景C2C、B2C、C2B2C的商品数据如何存储？个性化数据+共性数据

个性化数据放置在业务本地，会造成后期一些数据的孤岛

方案1 个性化数据每个业务一张表，系统的表将会爆炸式增长，不可控

方案2 一个公共表，一个个性化扩展表；假如个性化表最多64个字段可以满足需求，64个列，列的类型可以是Long，Double，text满足条件，则按照三个类型平分64列，key1...key64，将对应的key与业务个性化的字段做对应，比如key1->验机等，这个表就是映射表，但是存在数据空洞问题，相对而言空洞问题到还好是可控的。

方案3 从schema到no schema，比如NoSQL的MongoDB collection，数据库不需要知道存储的数据的语义，语义需要业务方去了解，但是不支持集群，扩展性有问题

方案4 方案2是列扩展，方案4行扩展，那么会出现什么问题？查询问题、数据量大、类型转化等(infoID,type数据类型1int等，key业务字段，value业务字段的值)

选择大于努力！！！考虑关键因素

业务中台数据统一存储，前台业务数据单独存储



企业级业务中台微服务架构高可用设计与实践（微博案例）

微博服务突发大流量

鹿晗事件 只影响鹿晗、关晓彤的微博不能访问了，隔离性比较好，其他人的微博还是可以访问的

热点问题如何解决？

问题产生原因或者瓶颈点在哪里？

1.数据库层面

2.缓存层面(redis cluster模式，数据肯定存在其中一台机器)

3.其他各层都是无状态，可以迅速扩展

读->压力

写->压力 feedId、feedContent...，异步化(点赞、转发、评论)

写放大

解决方案

热点分散(随着请求数量的增加，将热点数据分布到数据访问层的cache也就是进程间的cahce或者是本地缓存)

热点预测->预测系统，根据日志分析是否为热点，将热点数据push的本地缓存等



微博为何不能彻底解决大流量挂掉的问题？

ROI投入和产出不成正比，所以不会完全搞定的，秒级扩展不太现实(扩展需要时间)，除非是预留否则肯定会出问题，即使预留了超出了预留的极限也会出问题，618JD、天猫也会出现挂掉的case

优秀架构师快速成长之路（认知、思维、格局）

认知

思维

格局