纠结了,微服务和单体你选择哪一个?

                   
banq 18-08-10

本文是一篇微服务和单体架构比较文章,这类文章很多,但是比较的现象背后其实已经假设了一种先验的判断标准,这篇文章的言下之意是微服务比单体高级,对人员素质要求高,其实这是一种误解,微服务正是首先承认人理性设计能力不够,才用行动替代设计,先分成两三人的突击队上前线摸清敌情,相比单体的总体规划,然后再切分上下文来说,对人员的设计能力要求不高,以上只是banq个人意见,看看原文大意:

“微服务”正成为是行业的流行语,现在除微服务设计外,其余的设计被贴上“单体Monolith”标签,但作为一名架构师,当尝试基于某个领域开始创建新软件设计时,会不进行任何判断而直接采用微服务吗?只是因为它是受欢迎的?每个人都应该只是停下来考虑一下自己公司基础设施、员工专业知识、并在此基础上选择M微服务。

让我们看看微服务和单体的比较:

1. 项目相关人力资源:当你接到一个项目时,首先要考虑的第一个问题是在这个项目中将会有多少员工?他们的经历是什么。如果你的实力很低,比如那就不要使用微服务,因为微服务意味着独立的服务,而座右铭是“你建立它你就运行它”,所以应该有一个团队拥有完整的微服务所有权,如果你人力数量少,每一个或两个人将拥有两个或三个微服务的所有权,微服务数量大于人员数量,会产生一个关键问题:知识会仅限于他们之间,他们将成为中枢员工,另一方面根据“开发人员应该只关注一小部分”座右铭,但是在这种情况下他们了解所有的服务了,破坏了这一规则。

2.微服务及其相关知识:微服务是一种新的架构,有各种与微服务相关的概念,如分布式架构规则,如高可用性、弹性、服务发现、CAP定理、领域驱动设计、断路器模式、分布式缓存机制、路由跟踪等,不仅DevOps文化与微服务紧密结合,才能发挥微服务的全部功能,因此你需要了解CI / CD工具及其文化(自动部署)。团队应该高效地驱动所有这些微服务,如果微服务部署在云或容器中,团队应该了解云架构(PCF,亚马逊,Bluemix等)或Container架构(Docker,Docker Swarm,Messos,Kubernetes等)。

3.组织架构:另一个重要的维度是组织基础架构,在调整微服务之前总是检查组织工作的模式,根据Conway康威定律,你公司的组织结构已经反映到了代码中,那么首先请检查,你的公司是否采用了敏捷技术?是否构建了跨技术团队(如UI,中间层,数据库),什么是部署和QA测试模式?你的公司是否遵循手动部署和手动测试?或者他们已经或将要采用DevOps文化,其中待部署的发布包是什么? 公司有几个服务器?你可以在其中安装应用程序服务器并部署的发布包?或准备使用云?基于这些参数选择你是否会采用微服务。

3.领域关键性:检查你正在从事的领域性质,与业务分析师一起了解有很重要的,是否需要将领域拆分为子域,以便相关功能是否可以基于上下文的基础上封装,如果不是那就只好坚持单体了,因为不再需要创建上下文映射Context map并在有界上下文中封装子域了。

4.项目预算:这是另一个重要的方面。想想项目的预算,项目的性质是固定出价还是TNM类型。微服务项目比巨石更昂贵,因为它需要更多的服务器或云基础设施、自动化管道、资源数量,所有团队都应该是跨技能团队,因此在基础设施和资源水平方面它比单体成本高得多,所以想想你的预算与你的项目保持一致(偷偷地我给一个提示给你,请不要向任何人发布,作为一个优秀的忠诚架构师总是要考虑边际收入,模块化的单体比微型服务更好,如果预算很少,它可以达到你的目的收入,而且在未来如果你想迁移到微服务也是可能的。)

结论 :现在,新手或中级开发人员认为单体是一个大烂泥块,但如果你保持模块化的方法,它还是好的,在许多情况下,当我们的资源有限时,它比微服务更好。所以谨慎选择不要顺其自然,我总是建议首先使用单体,但是使其模块化,如果你使用Java9的模块,你可以从模块化开始采用SOA,当有实际需要时,比如模块边界会泄漏,或者你无法维护模块之间的非循环图(DAG),然后考虑在DDD上使用单体并且可以倾向于微服务。在此之前,我想说的是不要因为其他人正在采用微服务就用它,而是在你需要时采用它。 “伟大的力量来自伟大的责任”。

(banq注:该文渗透着一种对新技术和方法的恐惧和本能排斥,总是把新东西看得高大上,把很多新东西糅合成大烂泥块阻吓别人,微服务的好处是运行时的模块化和插件化,单体的模块化只能做到开发时的模块化。)
Microservice Vs Monolith:Which one to Choose? | Ma