小公司需要使用微服务架构吗?

微服务架构系列文章集合:https://www.cnblogs.com/jiujuan/p/17307285.html

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

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 点:这一阶段最重要的目的,产品概念验证(PoC),是快速把项目开发出来,让业务跑起来,给用户使用,快速验证想法,看能否对用户产生价值,验证产品是否沿着现阶段方向发展,还是另寻方向
第 2 点:因为在探索阶段,这时的产品结构和功能都不稳定,需求变化快,改动频繁,业务逻辑可能会经常变更。
第 3 点:这时产品功能少,不需要复杂的架构。要防止项目过度设计,影响开发进度。
第 4 点:你无法预知未来,什么未来?项目在未来是否会发展起来。

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

如果你能确定未来 1, 2 年内,项目会快速发展起来,那么适当做超前架构设计,是可以的。避免 2 年后业务起来,架构重构的诸多麻烦。尽量避免以后重构项目,带来大范围的改动。当然这样的架构设计也需要相当的功底。

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

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

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

从实际要解决的问题、场景出发去思考,而不是从技术本身思考。


说明:

这篇文章希望大家讨论在中小公司中,哪些情况下使用微服务架构,更适合公司业务。并不是说一定不能使用微服务,选择当下适合自己才是最好的。

如果大家意犹未尽,还可以到我的公众号继续讨论:九卷技术录 - 小公司需要使用微服务架构吗


下面是评论用户 Newbe36524 用工具 bing 进行的总结,觉得很有意思,我做一点小整理放在这里供大家参考:

new bing 这样总结到:
Q:
你好,我是想让你总结一下其中说的主要内容是什么 https://www.cnblogs.com/jiujuan/p/17116605.html

A:
你的问题是请帮你总结一下这篇文章主体的内容。我从网上搜索了一些相关的信息,发现这篇文章的主要内容是:

这篇文章是关于小公司是否需要使用微服务架构的讨论,作者分析了使用微服务的四大门派,分别是 跟风派技术派业务派架构派1。

  • 跟风派 是指那些盲目追随技术潮流,没有自己的判断和思考的人,他们认为微服务是一种万能的解决方案,可以提高开发效率,降低维护成本,提升系统性能和稳定性1。

  • 技术派 是指那些喜欢尝试新技术,追求技术创新,不惧怕技术挑战的人,他们认为微服务是一种技术趋势,可以让他们学习更多的技术知识,提升自己的技术水平,增加自己的市场竞争力1。

  • 业务派 是指那些以业务需求为导向,根据业务场景和规模选择合适的技术方案的人,他们认为微服务是一种业务架构,可以让他们更好地解决业务问题,提供更好的用户体验,实现更快的业务迭代1。

  • 架构派 是指那些有架构设计能力,能够从整体和局部的角度考虑系统的可靠性,可扩展性,可维护性,可测试性等方面的人,他们认为微服务是一种架构模式,可以让他们更好地构建和管理复杂的系统,实现更高的系统质量1。

作者认为,小公司是否需要使用微服务架构,没有一个固定的答案,需要根据自己的实际情况和目标来决定,不要盲目地跟风或者拒绝1。

作者建议,小公司在使用微服务架构之前,要考虑以下几个方面1:

  • 微服务架构的优势和劣势,以及适用的场景和条件
  • 微服务架构的实施成本和风险,以及应对的策略和措施
  • 微服务架构的组织和管理方式,以及配套的技术和工具
  • 微服务架构的演进路径和目标,以及评估和改进的方法和指标

作者最后总结,微服务架构不是一种银弹,也不是一种魔鬼,而是一种工具,需要根据自己的需求和能力来合理地使用1。


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


posted @ 2023-02-13 15:37  九卷  阅读(9348)  评论(53编辑  收藏  举报