9

小公司需要使用微服务架构吗？ - 九卷

 2 years ago
source link: https://www.cnblogs.com/jiujuan/p/17116605.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

一、使用微服务的四大门派#

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 派不妥之处是什么？#

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

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

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

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

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

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

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

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

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

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

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

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

第一：业务发展阶段

  • 业务刚开始探索时期

    这个时期最重要的目的是加快产品应用上市，验证产品是否匹配市场。这时是一个 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

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

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


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK