前言
前两年的市场绝对是微服务的天下，开发个什么系统，动不动就是微服务，几乎已经成为每个项目的标配。
但是，真的所有项目都适合微服务架构吗？什么样的项目适合微服务架构？我拿两个案例对该问题进行说明。
案例一：初创公司盲目使用微服务
2019年，我跳槽到一家初创公司。
公司要0开始打造一个社区团购平台，开发团队50几个人，工期6个月，时间紧任务重。
随着CTO的一声令下：“用微服务架构”。项目就开始了。
前面的一个月，大家都参与到需求的分析和设计中，最终后端的服务和应用加起来有30几个工程，几乎一个模块对应一个服务。
理论是完美的，但是在实际开发的时候却出现了很多问题：
- 服务间的调用总是莫名其妙的异常。
- 测试环境的链路每次都有新的问题出现。
- 正在运行的Docker容器总是莫名其妙的被删除。
- 30几个工程，每次发布都会出现问题。
还有等等问题。
在办公室也经常出现这些场景
这些问题的产生导致项目进度缓慢，无法按时完成。最终项目终止，团队解散。
而总是出现问题却没有得到妥善的解决，最重要的一个原因是：在这之前，团队中没有人有Spring Cloud实战经验。
我大概能确定，这是个事实。
因为我当时面试成功的主要一个原因就是：我“懂”微服务。
其实我懂吗？说实话，不懂。仅限于在本地运行过Spring Cloud的几个组件的演示示例，没有一点实战经验。对这些组件也是一知半解。
还有一个是我印象比较深刻的，鉴权中心这个服务是架构师跟着教学视频“一步步”敲出来的。
而且，自始至终，这个项目没有一个完善的监控、链路追踪、日志管理。
所以，我认为大家跟我的情况是一样的，是“懂”微服务的。
案例二：淘宝网不得已拆分单体应用
之前读过一本书《企业IT架构转型之道》阿里巴巴中台战略思想与架构实战。
有一个章节中写了淘宝网不得已拆分单体应用，大概是这样的：
在2007年，整个淘宝网还是一个几百兆字节的WAR包，大大小小的功能模块超过200个，团队规模有500人左右。
几百人维护一个WAR包就会带来很多问题：
项目团队间协同成本太高，业务响应越来越慢。
每一次的功能升级，各个团队会为各自负责的项目模块创建出新的代码分支，等系统上线时就会进行分支的合并。
做过开发的都会知道，在这个合并的过程中，会出现各种jar包冲突、代码不一致的情况，这就需要不同团队花大量时间去确认解决。如果再遇上有些功能开发的进度滞后，情况就会变得更复杂。
如果每一次的版本迭代都会有不少时间花费在这样的协同工作上，就会影响对用户的响应速度，要知道当时的淘宝是在高速发展期。
应用复杂度超出负载认知
淘宝从最初2003年发展到2007年，不管是功能的数量和业务流程的复杂度都在慢慢的提高。
面对越来越复杂的淘宝平台，没有一个人能完全清楚每一个功能和业务流程。这就意味着，一个小小的功能改动可能会影响其他的功能，从而造成一定的风险。
错误难于隔离
200多个功能模块集中在一个WAR包，但凡一个功能因设计不合理引起的功能迭代、代码质量差引起的应用崩溃，都会影响整个应用实例。
应用扩展成本高
通常出现业务瓶颈时都是某几个功能模块影响的，比如在大促时商品库存功能和订单创建功能的压力会非常大。
但是因为所有功能都在一个WAR包，所以在出现此类问题并且需要通过增加应用实例的方式分担服务负载时，只能将整个应用实例进行扩容，带来了额外的资源消耗，成本较高。
所以，淘宝网在每一次的操作都要牵一发而动全身的情况下，不得不对业务进行拆分。
什么样的项目适合微服务架构？
通过上面的两个案例可以明确：不是所有的项目都适合微服务架构。
如果你对项目拥有决策权，在用微服务架构前，不妨多问自己几个问题：
- 项目规模和复杂度是否匹配微服务架构？
- 引入微服务架构能否提高项目开发进度？
- 团队是否具备实施微服务架构的能力？
我正在参与2024腾讯技术创作特训营最新征文，快来和我瓜分大奖！
