终究选择了单体运用，保持了微办事架构

牛粪之恋

比来在做新名目的技术选型，因为业务简略，因此选择单体运用作为底座，上面是我做一下单体和微办事的比较。
假如把单体运用比作一条划子，那末微办事就是一个航空母舰的舰群。
部署一个单体运用和微办事的资源也是天差地别的。
单体运用所需资源
一条划子（办事器）一个渔民（开发者）一把浆（简略的开发工具和运维工具）使用场景：在小江小河中漫游（简略的业务场景）。

微办事所需资源
一个航母舰群（少量的办事器资源）一群船员和舰长（不同微办事的开发人员）一致指挥核心（K8s、Spring cloud等）其余使用场景：波澜汹涌的大海（繁杂业务场景）。

单体运用的益处
运用的开发很简略易于对运用顺序进行大范围的更改测试相对于简略直观部署简略明了横向扩展不费吹灰之力单体运用弊病单体运用天堂问题，此图来自微办事架构一书，如下：

单体运用天堂问题是名目办理变得难题，不同的团队使用同一个代码仓库进行开发，权限难以管制，且容易影响到其余模块的代码，跟着运用业务愈来愈繁杂，弊病愈来愈显著，详细如下：
适度的繁杂性（业务、代码）开发速度迟缓部署周期长（每次公布都需求编译全量代码）难以扩展代码隔离性差，不足牢靠性技术栈难以更新微办事的泛起就是为理解决单体运用的问题，它拥有下列劣势。
微办事架构的益处
使大型繁杂运用能够继续交付和继续部署每个办事都相对于较小且易于保护办事能够独立部署办事能够独立扩展完成团队自治容易对新技术进行验证及引入更好的容错性微办事架构弊病微办事架构看似弱小，其实带来了一堆问题，好比：
不易定义办事界限散布式零碎带来的繁杂性垮团队部署需求协调，需求制订公布方案如何定义界限定义界限时需求充沛了解业务，对业务进行良好的设计和拆分，倡议使用DDD来进行界限定义。
散布式带来的繁杂性
跨办事数据查问散布式数据统一性办事拆分办事治理办事追踪办事监控其余不外幸好的是，散布式带来的这些问题，目前曾经都有相对于成熟的解决计划。
总结
单体运用有本人的劣势，也有弊病，微办事架构也一样如斯。在做技术架构选型时，需求充沛斟酌现有的业务场景，结合业务进行选择能力更好的办事于业务，更为无利于产品的疾速迭代以及包管产质量量。切勿为了微办事而微办事，适合才是最佳的，不要适度设计！

华人澳洲中文论坛

热图推荐

终究选择了单体运用，保持了微办事架构

发表回复

牛粪之恋
关注TA

图文推荐

华人澳洲中文论坛

热图推荐

终究选择了单体运用，保持了微办事架构

发表回复

牛粪之恋 关注TA

图文推荐

牛粪之恋
关注TA