采用微服务架构前，先问自己几个问题

一时失言乱红尘 2024-04-25 08:37 42阅读 0赞

前两年的市场绝对是微服务的天下，开发个什么系统，动不动就是微服务，几乎已经成为每个项目的标配。

但是，真的所有项目都适合微服务架构吗？什么样的项目适合微服务架构？我拿两个案例对该问题进行说明。

## 案例一：初创公司盲目使用微服务 ##

2019年，我跳槽到一家初创公司。

公司要0开始打造一个社区团购平台，开发团队50几个人，工期6个月，时间紧任务重。

随着CTO的一声令下：“用微服务架构”。项目就开始了。

前面的一个月，大家都参与到需求的分析和设计中，最终后端的服务和应用加起来有30几个工程，几乎一个模块对应一个服务。

理论是完美的，但是在实际开发的时候却出现了很多问题：

*  服务间的调用总是莫名其妙的异常。
 *  测试环境的链路每次都有新的问题出现。
 *  正在运行的Docker容器总是莫名其妙的被删除。
 *  30几个工程，每次发布都会出现问题。

还有等等问题。

在办公室也经常出现这些场景

![170824ec7ac84fb19c593ab0120097c1.png][]  
![fe925a8342944c978a0ddd6c80bce86f.png][]

这些问题的产生导致项目进度缓慢，无法按时完成。最终项目终止，团队解散。

而总是出现问题却没有得到妥善的解决，最重要的一个原因是：在这之前，团队中没有人有Spring Cloud实战经验。

我大概能确定，这是个事实。

因为我当时面试成功的主要一个原因就是：我“懂”微服务。

其实我懂吗？说实话，不懂。仅限于在本地运行过Spring Cloud的几个组件的演示示例，没有一点实战经验。对这些组件也是一知半解。

还有一个是我印象比较深刻的，鉴权中心这个服务是架构师跟着教学视频“一步步”敲出来的。

而且，自始至终，这个项目没有一个完善的监控、链路追踪、日志管理。

所以，我认为大家跟我的情况是一样的，是“懂”微服务的。

## 案例二：淘宝网不得已拆分单体应用 ##

之前读过一本书《企业IT架构转型之道》阿里巴巴中台战略思想与架构实战。

有一个章节中写了淘宝网不得已拆分单体应用，大概是这样的：

在2007年，整个淘宝网还是一个几百兆字节的WAR包，大大小小的功能模块超过200个，团队规模有500人左右。

几百人维护一个WAR包就会带来很多问题：

**项目团队间协同成本太高，业务响应越来越慢。**

每一次的功能升级，各个团队会为各自负责的项目模块创建出新的代码分支，等系统上线时就会进行分支的合并。

做过开发的都会知道，在这个合并的过程中，会出现各种jar包冲突、代码不一致的情况，这就需要不同团队花大量时间去确认解决。如果再遇上有些功能开发的进度滞后，情况就会变得更复杂。

如果每一次的版本迭代都会有不少时间花费在这样的协同工作上，就会影响对用户的响应速度，要知道当时的淘宝是在高速发展期。

**应用复杂度超出负载认知**

淘宝从最初2003年发展到2007年，不管是功能的数量和业务流程的复杂度都在慢慢的提高。

面对越来越复杂的淘宝平台，没有一个人能完全清楚每一个功能和业务流程。这就意味着，一个小小的功能改动可能会影响其他的功能，从而造成一定的风险。

**错误难于隔离**

200多个功能模块集中在一个WAR包，但凡一个功能因设计不合理引起的功能迭代、代码质量差引起的应用崩溃，都会影响整个应用实例。

**应用扩展成本高**

通常出现业务瓶颈时都是某几个功能模块影响的，比如在大促时商品库存功能和订单创建功能的压力会非常大。

但是因为所有功能都在一个WAR包，所以在出现此类问题并且需要通过增加应用实例的方式分担服务负载时，只能将整个应用实例进行扩容，带来了额外的资源消耗，成本较高。

所以，淘宝网在每一次的操作都要牵一发而动全身的情况下，不得不对业务进行拆分。

## 什么样的项目适合微服务架构？ ##

通过上面的两个案例可以明确：不是所有的项目都适合微服务架构。

如果你对项目拥有决策权，在用微服务架构前，不妨多问自己几个问题：

1.  项目规模和复杂度是否匹配微服务架构？
2.  引入微服务架构能否提高项目开发进度？
3.  团队是否具备实施微服务架构的能力？

[170824ec7ac84fb19c593ab0120097c1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/25/137630f81e2742f3acd0e65f906646b5.png
[fe925a8342944c978a0ddd6c80bce86f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/25/b66f34a1c0864ddb8d11442eafa9d612.png

发表评论取消回复

表情：

评论列表（有 0 条评论，42人围观）

还没有评论，来说两句吧...

相关阅读

相关采用微服务架构前，先问自己几个问题

前两年的市场绝对是微服务的天下，开发个什么系统，动不动就是微服务，几乎已经成为每个项目的标配。但是，真的所有项目都适合微服务架构吗？什么样的项目适合微服务架构？我拿两个案...

一时失言乱红尘/ 2024年04月25日 08:37/ 0 赞/ 43 阅读

相关架构：微服务架构

系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为

古城微笑少年丶/ 2023年07月10日 08:59/ 0 赞/ 19 阅读

相关用 Spring 的 BeanUtils 前，建议先了解这几个坑

Java的小本家 2019-10-07 10:36:16 背景最近项目中在和第三方进行联调一个接口，我们这边发送http请求给对方，然后接收对方的回应，代码都是老代码。

妖狐艹你老母/ 2023年06月05日 12:52/ 0 赞/ 6 阅读

相关准备好进入数据科学领域了吗？先问问自己这14个问题

> 全文共3387字，预计学习时长9分钟 ![e05cbbd609b434d64dff4ecb6f29e299.png][] 图源：unsplash 数据行业被认为是增长

比眉伴天荒/ 2022年12月30日 08:15/ 0 赞/ 124 阅读

相关采用最终一致性解决微服务一致性问题

随着微服务的越来越多，一致性问题也越来越被重视。纠结是怎样才能ACID呢？CAP还是Base呢？其实强一致性的方案也特别多，比如net的msdtc、java的[atomikos

痛定思痛。/ 2022年06月09日 02:46/ 0 赞/ 279 阅读

相关微服务架构前篇

微服务的目的是有效的拆分应用，实现敏捷开发和部署。微服务架构的好处微服务架构模式有很多好处。首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功

桃扇骨/ 2022年05月29日 06:27/ 0 赞/ 142 阅读

相关老黄聊架构：微服务架构落地之前，需要想清楚的几个关键问题

无意中翻到的一篇很早关于微服务的理解性文章，写的挺好的，转过来以后可以多复习一下自从 2014 年“微服务架构”这个概念首次提出以来，在业界就引发了一股对微服务

﹏ヽ暗。殇╰゛Y/ 2022年03月15日 08:10/ 0 赞/ 206 阅读

相关【本人秃顶程序员】提交代码前问自己七个问题！

←←←←←←←←←←←← 快！点关注为什么写出好的代码是如此之难？为什么经过了这么多年的努力，有这么多的最佳实践/工具/方法学（例如：瀑布式开发，迭代开发，Scrum

朴灿烈づ我的快乐病毒、/ 2022年03月01日 00:52/ 0 赞/ 212 阅读

相关微服务基础架构的5个关键问题

> 作者介绍： > 杨波，微服务技术专家，曾主导了拍拍贷微服务架构体系建设。任职携程技术研发总监期间，主导了携程大规模SOP体系建设，也是极客时间「微服务架构实战160讲」

￡神魔★判官ぃ/ 2022年02月22日 08:27/ 0 赞/ 235 阅读

相关全面掌握Spring Boot与Kubernetes云原生微服务架构实践——为何采用微服务架构

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ub

布满荆棘的人生/ 2021年07月25日 19:24/ 0 赞/ 388 阅读