高并发高可用高可靠微服务架构7大顶级设计思维模型

Posted 2021-04-23 架构师

昨晚睡前，撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”，顺藤摸瓜翻了一下聊天记录，大致内容就是某公司在做微服务改造，但改成了四不像，形式上像微服务，本质上依然是单体，甚至连单体都不如。

这样的改造现象，其实还蛮多见的。过程就跟铺管道似的，不停地在马路上挖开、埋上、挖开、埋上…

先思考1个问题：从单体改造到微服务的时候，你们是不是按这样的步骤来的？

1、确定业务领域，拆分存储，定义各微服务的边界；

2、改造代码逻辑，将原来的内部service调用改成dubbo或feign这样的远程调用。

这样一顿操作，把一个臃肿的单体应用变成了多个精炼的分布式应用，似乎完美的实现了改造？但这样就实现了微服务的核心目标了吗？继续思考下面的问题：

1、代码库是分开了，但每个服务都在独立迭代吗？是不是每个需求都要协调一大堆同步接口？

2、CI/CD是分开了，但每次发布都是自由的吗？是不是每次功能的发布都拖上了一大推的服务要一起发布？

3、数据库是分开了，但似乎有个服务挂了，依然导致很多功能就都不正常了？

01

微服务改造为啥走了样？

改造不伦不类，主要有两方面原因：

1、领域拆分的不合理，引出了过多的同步远程调用

这个是最根本的问题，也是在改造过程中最常见的。这部分说实话是整个改造过程中最难的，因为需要对业务有非常深入的认识，对系统设计的领域模型、用户行为有足够的理解。

2、简单粗暴的实现，缺少分布式的保护机制

在很多团队里，因为业务需求多与人员配置少的矛盾之下，开发人员很容易出现对远程调用不做足够的保护机制，比如：

接口提供方的限流策略（保护自己不被别人搞死）；

接口调用方的降级策略（保护业务更高的可用性）；

接口调用方的熔断策略（保护自己不被别人拖死）。

怎样才能减少改造所带来的稳定性损失及牵连出的诸多问题呢？

曾经和玄姐（前58集团技术委员会主席、阿里云MVP、腾讯云TVP）探讨过关于架构设计的思维模型，收获颇多。

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

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

 

4月12日 - 14日，每晚20:00-22:00

不赚钱，交个朋友！

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

长按扫码