1、使用微服务的四大门派

2.1、跟风派

技术大环境分析，到目前为止（2023.02）技术大环境:

• 各大公司都在宣传微服务以及自家实践情况
• 各种技术媒体也发布很多关于微服务的文章
• 和别人讨论技术相关的架构时，必然会提到微服务架构

这样的氛围下，微服务这 3 个字时不时的出现在眼前，加深你对它的印象。有时会给人带来一种“幻觉”，如果自家公司技术不进行微服务的升级改造，技术就会落后于它们，对技术产生焦虑感.

这种属于 “跟风派” 。完全没有考虑自家业务发展情况，反正别家公司都是这么做的，我也要这么做.

2.2、追新派

有的技术人，在出现新的技术时，都想要在自家业务上对新技术实践一番，以此体验新的技术给他们带来的一种“技术快感”.

“我使用了 NB 的技术”。为了技术而技术.

我意思不是说，对新技术不追求.

对于个人而言，这是一种“活到老，学到老”的积极学习态度，是值得大加提倡.

对于公司而言，需要考虑的情况比较复杂，至少有以下 3 点:

• 新技术出现的相关背景
• 新技术有哪些特性
• 公司现阶段业务有哪些问题？新技术真的能解决这些问题吗？

这种喜欢新技术的人，可以做公司技术预研，为将来遇到合适的业务应用这种技术打好基础.

2.3、简历派

好多招聘 java 开发的，都写着一个技能要求，熟悉 springcloud 并使用.

springcloud 是 java 语言的一个微服务开发技术栈大集成框架.

招聘，这也导致一些人尝试使用微服务架构，为一下次跳槽做好准备.

这种情况于个人是一种驱动力，于公司则需要三思而行.

可能会留下一堆乱摊子 - 遗留的“烂”代码.

2.4、革新派

这一派主要是在“大泥球”单体开发上遇到了种种问题，想用新的技术架构-微服务架构来解决.

“大泥球”单体的问题 :

• 代码腐化：业务代码经过长时间的迭代，有很多重复代码。比如一个功能可能有 3,4 种实现。
• 业务逻辑交织：业务应用经过长时间发展，功能变多，业务功能里的逻辑代码可能相互引用，交织不清。
• 代码复杂：功能多，业务逻辑复杂，只有少数员工能理解。这也是代码腐化一种。
• 维护性变差：修改 bug 或增加新功能时，牵一发而动全身。一个 bug 没修好可能导致整个软件不可用。
• 扩展性变差：增加新功能时，牵一发而动全身。
• 编译发布变长：软件代码量大，编译时长变长，导致发布时长也变长。

等等各种问题.

为了解决上面的问题，就想到微服务架构。微服务架构最基本的一个点：分而治之，由大化小。目的就是把一个大单体划分为各种微服务，松耦合，独立自治.

微服务的优点 :

• 松耦合：划分为一个一个小的微服务，代码之间逻辑交织降低.

• 独立部署：每个划分的微服务都是一个独立的项目，可以独立部署.

• 编译发布改善：划分为独立的小项目，编译时长变短，发布时长相应变短.

• 故障隔离：由于划分为一个一个微服务，故障仅发生在独立的微服内.

• 可扩展性：每个服务可以独立横向扩展，也可以从应用程序中提出独立功能变成服务，扩展变强.

• 职责单一团队：每个小的微服务都由一个小型的高度专注的团队负责.

• 技术异构：每个团队可以选择适合该业务的技术.

看着微服务的这些优点，看着是解决了大单体的问题.

但是微服务自身就没有缺点吗？有的，整体架构复杂度变高.

微服务的各种缺点 :

• 调用复杂性：单体应用是在本地调用，微服务是通过网络调用，有的还需要调用多个其它服务才能完成一个功能，其它服务不可用怎么办?

• 分布式复杂性：分布式数据一致性，分布式事务问题.

• 部署复杂性：服务变多，部署起来也变复杂。所示基础设施CICD就变得重要.

• 服务治理：服务出现问题，找到问题的链路变长，所以就有链路监控。还有服务隔离和容错.

• 测试复杂性：集成测试变得复杂，毕竟服务多.

• 运维复杂性：服务变多怎么定位问题？怎么保证服务稳定?

• 团队协调复杂：微服务划分后就涉及多个团队沟通协作了.

等等，都是技术上遇到的问题。这些微服务的缺点也需要高度注意.

如果实施微服务，那么技术基础设施也需要及时跟进.

2.5 上面 4 派不妥之处是什么？

对公司现阶段业务实际情况进行调查，遇到了哪些问题？一一列出.

微服务架构能解决哪些问题?

两者之间是匹配的吗？如匹配，匹配多少呢?

大公司或者技术媒体关于微服务架构的文章，我们当然要学习消化，然后想在公司立马应用起来.

这里有一个根本问题就是:

发文章的人并不了解你公司的具体情况。公司现在有多少业务？每条业务线技术情况是什么样？有哪些问题？开发人员有多少？业务用户每天访问量有多少？等等，都不清楚。我们也不是淘宝、腾讯、京东这样的大公司，他们这些技术方案都适合自己公司现状吗?

我们最后还是要关注自己公司情况，要 具体问题具体分析 .

按照公司现阶段条件和问题做适当的选择.

2、小公司需使用微服务架构吗？

这里所说的小公司，是指后端研发人员较少，30 人左右，项目数量 6 个左右。平均下来每个项目共有 5 名研发人员.

这样的人员配置适合微服务架构开发吗？适不适合要从各个方面来评估.

我前面也有写微服务架构适用场景分析:

• 微服务架构学习与思考(05)：微服务架构适用场景分析 。

• https://www.cnblogs.com/jiujuan/p/13762969.html 。

第一：业务发展阶段 。

• 业务刚开始探索时期 。

  这个时期最重要的目的是加快产品应用上市，验证产品是否匹配市场。这时是一个 MVP 产品，功能少，适合用单体来快速开发.

• 高速发展时期 。

  产品验证取得了初步成功，进入业务快速迭代阶段。这个阶段一般也是用单体架构，快速开发功能.

• 产品稳定时期 。

  业务功能迭代没有那么快，这时可以思考架构的问题，并寻找解决方法。微服务也只是一种比较好的选择.

第二：业务复杂度 。

• 业务功能多，流程错综复杂，只有少数人能看懂，功能交付变长。这时可以利用改造微服务的机会，来梳理业务流程，理清彼此之间关系。
• 如果是相对简单业务，那么没必要使用微服务。

第三：开发人员 。

• 技术熟练度 。

  对微服务技术做了相应的预研，并且做了对应的练习实践，对微服务涉及的技术有一定实践经验.

  微服务技术体系本身就是由很多系统组成，技术体系本身就有一定的复杂性.

• 开发人员质和量 。

  划分微服务后，人员数量是否满足划分后的微服务？还是划分后大家完成需求比较急?

  微服务架构涉及到了很多技术系统，对人员技术要求也更高.

第四：业务形态 。

• 如果你是那种对性能要求很极致的业务，比如金融股票交易系统、游戏里的战斗系统灯光。这种就不适合，因为微服务网络调用相对于单体本地调用的开销肯定更大。

更多需要考虑的点请查看这篇文章： https://www.cnblogs.com/jiujuan/p/13762969.html 。

为什么要考虑业务发展阶段呢?

如果是项目刚启动，第 1 点：要快速把项目开发出来，让业务跑起来，给用户使用，看能否对用户产生价值。第 2 点：这时的产品功能不稳定，需求变化快，改动频繁。第 3 点：这时产品功能少，不需要复杂的架构。要防止项目过度设计，影响开发进度。第 4 点：你无法预知未来，什么未来？项目在未来是否会发展起来.

所以一般建议：一开始就用复杂微服务架构来做开始启动的项目，不是一个良好的决策.

如果你能确定未来 1, 2 年内，项目会快速发展起来，那么适当做超前架构设计，是可以的。避免 2 年后业务起来，架构重构的诸多麻烦.

遗憾的是，多数创业项目撑不过 2 年就以失败告终.

刚开始的项目，单体架构是一个好的建议，需做好相应的模块划分。然后随着业务的发展，架构也随之演进。 我前面的文章 “单体架构到微服务架构演进”： https://www.cnblogs.com/jiujuan/p/17066590.html 。

演进架构 是一种很好的架构方法，值得多思考.

---

以上就是九卷的一点看法，如有不对不妥的地方，欢迎大家批评指正.

最后此篇关于小公司需要使用微服务架构吗？的文章就讲到这里了,如果你想了解更多关于小公司需要使用微服务架构吗？的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。