纠结了，微服务和单体你选择哪一个？

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