微服务架构核心复杂问题解析：分布式事务服务治理负载均衡

Posted 2021-05-15 逸言

我们都知道微服务有很多优点，比如去中心化、松耦合、自治、独立性，这方便我们实现快速扩容、灵活部署。

我们之所以抛弃单体，拥抱微服务，往往是因为开发效率、代码维护、部署灵活度、稳定性、扩展性等持续走低综合作用的结果。

 

这是不得不为的结果，也是很多大厂早早部署的原因，“谁先痛谁先动”！发展到现在微服务的确已经成为主流架构。

 

当然，没有任何技术是完美的，我们要看到光鲜的背面，背面才是考验技术人真本事的关键要素。拆分前我们需要思考以下问题：

进行服务拆分，边界在哪儿？怎么取舍？什么样的粒度才符合“高内聚、低耦合”；

分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，如何权衡？

同时，在改造过程中我们仍然需要关注微服务牵连出的诸多问题：

 

1、多个相同的微服务可以做负载均衡，提高性能和可靠性，但微服务本身是不会去关心系统负载的，什么时候该启动更多的微服务，多个微服务的流量如何调度和分发，这背后需要有一套复杂的负载监控和均衡的系统发挥作用。

 

2、微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。

 

3、单个微服务拥有自己的进程，进程本身可以动态的启停，为无缝升级打好了基础，但谁来启动和停止进程、什么时机进行、选择哪台设备才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的部署能力。

虽然有很多问题需要我们解决，但有1点需要明确， 这不是微服务的锅，而是规划和架构设计不到位的锅。

这的确是一个庞杂的系统性问题，曾经和玄姐（前58集团技术委员会主席、阿里云MVP、腾讯云TVP）探讨过关于微服务架构设计的思维模型，收获颇多。

作为百万年薪架构师的顶级思维模型之一：根据（业务）场景Balance的架构设计思维模型。BAT超一线大厂架构设计固然优秀，但照搬拷贝就变得很可笑。身为一名顶级架构师，你需要根据所处公司的业务特点、请求并发、数据规模等场景给出灵活优雅的架构设计解决方案，满足公司未来6个月到2年的业务发展需求。

玄姐把对微服务架构的深入思考，联合快狗打车CTO沈剑，不断打磨、凝练，熬出了一套最新的，包含 3 大篇章16个模块的在线专栏课（原价499，限时优惠价9.8 ≈ 半杯奶茶，相当划算）！

 

5月17日 - 19日，每晚20:00-22:00

不赚钱，交个朋友！

原价 ¥499，限时 ¥9.8 立刻学习！