最近有看到“微服务，分久必合、合久必分”的言论，我同意，微服务不是架构演变的终点，细说还有Serverless、FaaS等方向。但纠结要不要拆分是没有必要的，拆往往是随着业务变化不得不的选择。
我们都想要敏捷，也正是对简便快速的追求让底层架构一步步失衡，牵连出的不合理设计增加了业务复杂度，为产品后续迭代埋下隐患。
当然盲目进行微服务改造绝对是给自己找麻烦，这里简单梳理下改造具体步骤：
1、调整代码结构，分析模块间依赖
2、考虑安全问题，添加测试保护
3、消除业务代码依赖
4、分离单元测试代码
5、跨聚合SQL查询和信息冗余处理
6、服务拆分，跨服务接口上升到BFF，引入Toggle
7、拆分数据库
这些步骤看起来简单明了，而现实是我们往往会因为对服务非常熟悉而轻敌。实操过程中会出现很多意想不到的问题：
整个应用分散成多个服务后，定位故障点变得困难。
一个服务故障可能导致整个系统挂掉，稳定性下降。
服务数量非常多，部署、管理的工作量很大。
在编程的世界中，最重要的便是抽象能力。微服务改造的过程实际上也是个抽象的过程。这既是技术层面的重构，也需要对业务有非常深入的理解。
业务现状、拆分原则、项目痛点、降本增效都是我们进行架构重构过程中需要考虑的重点要素。
这的确是一个庞杂的系统性问题，牵一发而动全身。曾经和玄姐（前58集团技术委员会主席、阿里云MVP、腾讯云TVP）探讨过关于微服务架构设计的思维模型，收获颇多。
作为百万年薪架构师的顶级思维模型之一：根据（业务）场景Balance的架构设计思维模型。BAT超一线大厂架构设计固然优秀，但照搬拷贝就变得很可笑。身为一名顶级架构师，你需要根据所处公司的业务特点、请求并发、数据规模等场景给出灵活优雅的架构设计解决方案，满足公司未来6个月到2年的业务发展需求。
玄姐把对微服务架构的深入思考，联合快狗打车CTO沈剑，不断打磨、凝练，熬出了一套最新的，包含 3 大篇章16个模块的在线专栏课（原价499，限时优惠价9.8 ≈ 半杯奶茶，相当划算）！
5月10日 - 12日，每晚20:00-22:00
不赚钱，交个朋友！
原价 ¥499，限时 ¥9.8 立刻学习！
