单体 vs 微服务架构

FROM：https://medium.com/startlovingyourself/microservices-vs-monolithic-architecture-c8df91f16bb4

当下这个无微服务不架构的时代，我们身在其中，已然没有选择。
随着微服务的兴起，带动了一大堆新的概念或者曾经的技术或理论又重新被赋予生命力，诸如康威定律、敏捷开发、DevOps、CICD、DDD、RPC等不一而足。
而我今天就不去追究其产生的背景和历史发展等上下文，而是结合自己的感受，简单的来讨论一下单体和微服务架构下的优点和弊端，以及合适的采用场景。

单体架构

简单的理解，就是一个产品（或项目）一个交付物，如果是Java开发的话，通常是一个带有单一入口的WAR/JAR包，所有的业务逻辑全部包含在这个文件里，或许是通过模块化开发后集成，分层设计，最终从上到下形成一个不可分割的整体。

例如：

一个电商系统，包括的订单、商品、运输、用户、支付等模块都在一个系统里面，提供单一的REST接口和前端以及数据库。

优点

1. 容易实现，完全不需要考虑分布式相关的任何问题，例如，进程通信、事务；
2. 端到端的测试非常方便，没有或者很少外部依赖，不需要协调外部资源，例如目前所在的公司，就要求生产系统的9999保证以外，还要求Beta环境达到999的SLA，以免影响相关团队的联调测试；
3. 运维成本，更容易部署，也更容易扩展，这个无需多说。

弊端

1，大泥球
随着时间的推移，一个单体应用很容易发展成为一个大泥球，架构的设计被腐化，模块边界模糊。
后期增加新的功能越来越困难，改动一个地方，往往会影响好几个功能，牵一发而动全身，每改变一处，都有潜在的副作用，最终发现，大家都不敢直接修改，从而是产生大量重复的代码；

2，扩展成本
单体应用早期便利的扩展优势，随着规模变大，整体扩展将变为一种负担，无法单独对某个部分进行扩展，每个实例都将占用完整的资源；

3，强耦合
耦合可以分为模块之间的耦合和技术框架的耦合，模块之间很难做到容错，一个BUG可能会拖慢整个服务，也可能挂掉整个应用；
而框架层面的耦合则体现在对现有技术改进时的无奈，你会发现，模块之间的框架依赖必须是统一的，新版本的框架和技术你是无法单独引用，更无法使用异构技术，只能受制于当前状态下，进行微观优化。

微服务架构

microservice

设想一下，如果你把单体架构的模块独立成服务，是不是就变成微服务架构了？
其实是的，只是要解决服务之间的交互问题。在单体架构下强调的模块之间的高内聚、低耦合，在微服务架构下就变成针对每个可以独立开发和部署，通过接口解耦的服务了，但这俩个原则同样有效，

因此，微服务是松耦合的面向相互交互的服务，组成或完成整个业务系统的架构。

例如：

还是那个电商系统，而现在，每个模块变成一个独立的角色完备（有单独的接口、DB等）的服务了，服务之间可以通过不同的RPC协议（例如REST、gRPC等）跨越边界，进行通信和交互。

至于如何拆分服务，其实在单体架构同样类似的问题，如何划分模块，如何定义Domain，目前在微服务架构下，DDD是大家比较认可的服务拆分方法论，其实，它同样也适用于单体架构！

优点

1. 低耦合
   更容易做到高内聚低耦合，因为服务是独立的，从一开始就完全解耦，边界清晰，所以更容易保持各自的模块化实现；
2. 复用
   大部分采用微服务架构的公司，一个微服务有一个独立的团队来长期维护，对外提供标准的不同版本的接口，只要其他产品有此类需求，就可以对接，一个微服务，可以在多个产品中复用；
3. 高效
   由于服务本身所承担的业务功能的单一，决定它的规模和体积都不会太大，并且有独立的维护团队，使得沟通、项目编译启动的速度、测试、部署CICD 都变得会非常高效；
4. 异构性
   每一个微服务可以有自己的技术选型，技术实现相互隔离，可以选择更好的满足自身特点的技术，并且老的服务可以更容易的完成自我重构和技术迭代升级；
5. 故障隔离
   相对单体架构，这一点更容易做到，故障的影响范围可以缩小到故障服务自身，通常使用熔断、降级等手段，提升整个系统的稳定性（举个例子，微服务之间的调用本应该有auth验证，但是当获取token的auth服务不可用时，降级策略是用临时token跳过验证）。

弊端

任何事情，如果被大多数人认可，便会成为真理。

微服务架构的盛行亦是如此，但作为没有银弹的实践科学，我们必须要思考它的不足，微服务本质是一个分布式系统，他就天然有分布式系统的复杂性，例如处理部分服务故障、更复杂的端到端测试、网络通信的困难和不确定性等。

分布式事务，
这是目前分布式系统依然很难面临的难题，目前有很多折中的解决方案，基于XA的2PC、3PC和Saga，柔性事务等最终一致方案，但是在实践中依然显得笨重。

运营维护，
微服务架构需要做的运营工作跟单体架构相比，工作量差别巨大，微服务需要引入大量中间技术，服务注册、发现、调用链、安全、网关等，都有所增加或更加复杂，需要强大的基础平台配套做支撑，才能使得微服务这种架构的落地更为稳妥，例如公司配套PaaS和APM平台来完成CI/CD、DevOps，这些都是非常必要的。

成本，
包括硬件成本和团队之间的协作成本，显然，微服务架构需要更多的硬件资源，当然这在规模扩大到一定程度后显得不是那么重要，由于单体架构本身存在着一定的扩容浪费，微服务可以选择性的扩容。
另一个成本问题是团队之间的协作，多个团队之间的默契程度必然要低于一个团队，所以公司需要推行一些工作文化，例如用户思维，产品思维等，消除团队障碍，扁平化、团队自组织、自驱动、价值导向，于是，这就是敏捷文化。
所以，微服务、敏捷文化是密不可分的孪生兄弟，技术方法论&组织精神。

如何选择

还是那句话，任何技术和理念都将不能成为解决一切问题的银弹，有的只是权衡和选择！

首先，是你的组织架构，如果你的团队是线性（多重角色，开发、测试、产品、前端）的方式划分，而不是垂直（相同类型的技术划分，前端团队、后台团队，产品团队、测试团队等）划分，假如有N个这样的团队，在各自负责一个产品
，那么，这种组织适合微服务。

而如果，你是一个小而精的团队，10个人的团队？这种情况几乎可以肯定，单体架构更适合你（康威定律，别让简单事情复杂化）。

其次，考虑变更效率和复杂性的权衡，更高的变化响应效率，意味着更高的复杂性，采用微服务满足前者，而单体架构则解决后者的问题，俩者之间需要决策者权衡。

然而无论如何，在我们还不确定采用哪种架构的时候，或初创，最好采用MVP的思路，先从单体架构开始，为了长远考虑，尽量保持良好的模块化开发，在未来的某一天，时机成熟，如果你决定要将这个单体应用拆分为微服务架构，这将是一件相对顺理成章和轻松的事情。

小结

从趋势来看，个人认为，微服务盛行的很重要的一个原因是技术对市场变化的响应速度的提升，话句话说，就是保持产品对市场的适应能力，能够快速响应市场的变化，满足用户的增量需求，而微服务就是一种非常强的适应性架构。

FROM：https://medium.com/@achardypm/how-to-scale-scrum-teams-8a7b53390194

从 人月神话 和 康威定律 中我们也能看到这一点，前者说项目走到后期，增加开发人员只能让开发进度变得更慢（明显这是针对单体架构的，一个大团队，有更高的沟通成本），而后者康威定律则强调的是怎样的组织结构就会产生怎样的产品形态。
所以，要想让你的产品更快交付，就要调整你的组织结构（划分敏捷团队，可以让更多开发者参与到项目中），因此，微服务就必须要将康威定律和敏捷绑定在一起，重新设计你的组织结构，进而需要重新定义团队的工作方式，才能实现从组织结构到技术实现的微服务化。

微服务从技术设计角度可以理解为是一个更高维度的空间换效率，空间包括了更多的硬件（服务器、网络等）资源 、 人力（不同的全栈团队）资源和更庞大的组织结构（大量的敏捷团队），蜂群效应，从而换取更高的交付效率，更快的市场响应能力。

参考

1. https://programmerfriend.com/monolith-vs-microservices/