江苏龙网

  1. 主页 > 生活百科 > >

75% 新项目都可以“无脑”选择单体架构( 四 )

单体架构


 
这很快就会引发冲突，大家发现单体式架构太过“拥挤”，容不下大规模作战 。微服务的要义就是把单一团队的工作从整体代码库中抽离出来，形成新的独立代码库 。这样人们才能并行工作，保证不对其他开发者的行动产生干扰 。
 
但这个适合微服务架构的规模临界点在哪里？我不太清楚，具体要视组织情况而定 。如果管理者既不负责、也没水平，那 10 个人就足够把项目搅成一锅粥了 。但在这样的团队里，难道微服务就能发挥作用？我压根不信 。
总结从负责任的角度出发，我不会轻易断言大家该用单体式架构、还是微服务架构 。
 
我的个人看法是，这个艰难的选择无法回避、必须在项目起步阶段就预先设定完成 。我觉得大概四分之三的新项目都可以无脑选择单体式架构，再配合适当的模块化设计保证后续有必要时能比较轻松地转化成微服务架构 。那什么叫“有必要”呢？就是转化的工作量低于继续维护原有单体式架构的工作量时 。
 
剩下的四分之一可能天然更适合微服务架构，但还是要先整理出明确的理由 。总之，如果不假思索地盲选，我个人肯定是先单体、后微服务 。
 
架构判断绝非易事，我们需要对产品做出未来一到两年的发展预期、估算未来会有多少人/什么样的人参与到项目中来，会有哪些基础设施限制，我们的预算、产品功能路线等等 。综合各项因素，最后得出的才是安全可靠的架构决断 。
 
如果你的产品只是一款普通的终端消费级 Web 应用程序，例如网上商店，日活用户 5000 左右，前五年月均订单量 100 份上下，那就完全没必要选择微服务 。另外，如果你的初始团队是一位老手带多位新手，那微服务同样不太适用 。最后，如果项目预算有限，同样记得远离微服务——它带来的很可能是一套没人愿意维护的混乱系统 。
 
微服务这个概念属于听起来简单，做起来却极为困难 。相信我，没人天生就能编写出完美的微服务项目，我们都需要不断摸索和学习、围绕新概念打磨自己的业务水平 。虽然开发顶尖单体式应用程序的难度也不低，但它的结构特性更符合我们的思维本能 。而单体式架构中最难学习的正是模块化、可测试性、关注点分离等要素，也就是那些跟微服务架构最相似的部分 。本篇文章到此为止，总之，两种架构各有各的挑战 。

75% 新项目都可以“无脑”选择单体架构

文章插图
 
你给解释解释，什么叫微服务？




推荐阅读


上一篇：FRP 内网穿透、反向代理

下一篇：超级好用的生产力写作工具Notion介绍