微服务那么火，我也该用微服务吗？

前言

近来，几乎人人都在谈论微服务。开发人员都在研究Eric Evan的著做《领域驱动设计》。团队正在重构一体化应用，寻找限界上下文，并定义通用语言。虽然有不可胜数的文章、视频和座谈能够帮助您转换到微服务，但不多有人愿意多花些时间来探讨一下某个具体的应用是否应该采用微服务。

使用微服务架构有不少充分的理由，但天下没有免费的午饭。微服务虽有诸多优点，但也增长了复杂性。团队应该积极应对这种复杂性，但前提是应用可以受益于微服务。

切忌盲目跟风，请负责任地考虑是否采用微服务架构

Matt Stine和我在最近与一家客户一块儿研究了他们的一些应用。咱们的讨论以“一切都应该是微服务”为出发点，由于这在现在已经“司空见惯”。结果谈话陷入了僵局，你们就各类实施细节争论不休。

Matt在白板上写下了一组原则。这些简单的句子在这一天剩下的时间里指导着咱们，咱们审视应用架构的每一个部分，寻找微服务能够交付价值的地方。这个列表完全改变了对话的氛围，帮助团队制定了明智的架构决策。

为了避免滥用微服务，咱们列出了这组原则，帮助您集中精力开展工做。经过阅读下面的这些原则，看看特定的应用可否因某一个原则而受益。若是对于如下一个或多个原则，您的回答是“是”，那么这个功能就适合采用微服务。若是对于每一个原则，您的回答都是“否”，那么您可能会给系统引入偶发复杂性。

01

多个变动速度

系统的各个部分是否是须要以不一样的速度或向不一样的方向发展？若是是，就分别采用微服务吧。这让每一个组件都有了独立的生命周期。

在任何系统中都是一些模块不多受影响，而另外一些模块彷佛每次迭代都会发生变化。咱们来举例说明，假设有一款用于在线零售的一体化电子商务应用。

在平常开发工做中，购物车(Cart)和库存(Inventory)功能基本上不会受影响。但咱们可能会不断地试验推荐引擎(Recommendation Engine)。咱们还想努力提升搜索(Search)能力。若是将这两个模块分别放入微服务中，它们的团队就能以更快的速度进行迭代，从而让咱们快速交付业务价值。

02

独立的生命周期

若是一个模块须要有彻底独立的生命周期（是指代码提交到生产的流程），那么它应该采用微服务。它应该有本身的代码存储库、CI/CD pipeline等。

范围越小，测试微服务就越容易。我记得之前遇到过一个项目，它的回归测试套件须要80个小时！不用说，咱们并无常常执行完整的回归测试（虽然咱们真的想这么作）。微服务方法支持精细的回归测试。这为咱们节省了大量的时间。咱们可以及早发现问题。

测试不是咱们采用微服务的惟一理由。在一些状况下，业务需求可能促使咱们采用微服务架构。让咱们以Widget.io一体化应用为例。

企业领导可能发现了新商机，而上市速度相当重要。若是咱们决定向一体化应用添加必要的新功能，可能要花很长时间。咱们的行动速度没法达到企业的要求。

但做为独立的微服务，“项目X”（以下所示）能够有本身的部署流水线。这个方法使咱们可以迅速迭代，重新的业务商机中获利。

03

独立的可扩展性

若是系统各部分的负载或吞吐量特征不一样，它们的扩展需求可能也不一样。解决方案就是把这些组件放入独立的微服务中！这样一来，服务可以以不一样的速度扩展。

即便粗略地看一下通常的架构，咱们也会发现不一样模块具备不一样的扩展要求。咱们从这个角度看一下Widget.io一体化应用。

最有可能的状况是，其中的账户管理(Account Administration)功能并不须要承受订单处理(Order Processing)系统承受的那么多压力。过去，咱们必须扩展整个一体化应用来支持最不稳定组件。这种方法会致使基础架构成本增长，由于咱们不得不在应用的某个部分出现最坏状况时“过分调配”。

若是将订单处理(Order Processing)功能重构为微服务，咱们能够根据须要扩展和收缩。结果就如这张图所示：

04

隔离故障

有时，咱们但愿将应用与特定类型的故障隔离开来。例如，当咱们依赖一项外部服务但这个服务没法知足咱们的可用性目标时，该怎么办？咱们能够建立微服务，将这种依赖关系与系统的其他部分隔离。以后，咱们能够在该服务中构建合适的故障转移机制。

在这里顺便给你们推荐一个架构交流群：617434785，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。相信对于已经工做和遇到技术瓶颈的码友，在这个群里会有你须要的内容。

再来看一看咱们的示例Widget.io一体化应用。库存(Inventory)功能刚好与一个遗留的数据仓库系统交互，然后者的正常运行时间不够好。若是将库存(Inventory)模块重构到微服务中，咱们就能够在可用性方面实现服务级别目标。咱们可能须要增长账户冗余以应对脆弱的数据仓库系统。咱们还能够引入一些最终一致性机制，好比Redis中的缓存清单。但如今，转型到微服务减轻了因为不可靠的第三方依赖关系而致使的性能不佳。

05

简化与外部依赖关系的交互

这个原则与“Isolated Failure”相似。换一种说法是：咱们更专一于保护系统免受频繁变化的外部依赖关系的影响。（这也多是供应商依赖关系，即把一个服务提供商换成另外一个，好比更换负责付款处理的供应商）。

微服务至关于一个间接的层，把您与第三方依赖关系隔离。咱们能够在核心应用与依赖关系之间部署一个由咱们控制的抽象层，而不是直接调用依赖关系。此外，咱们能够构建这个抽象层，让应用更便于使用，由于隐藏了依赖关系的复杂性。若是将来发生变动，必须进行迁移，那么变动将只限于“外观”，不须要更大规模的重构。

06

根据工做自由选择合适的技术

利用微服务，团队能够自由使用本身喜欢的技术堆栈。在某些状况下，一项业务要求刚好适合一项特定的技术选型。而其余时候，技术选型由开发人员的偏好和熟悉程度决定。

注意：这个原则并非说能够随意使用任意技术！请向团队提供关于技术选型的指导。过多的分散堆栈会在认知上增长开销，比基于“一刀切”模型实现标准化更糟糕。为一个堆栈及时更新第三方存储库就已经颇有挑战性了，更况且是将这种费力工做扩大四倍或五倍，会大大增长公司的负担。请采起有效措施，关注那些您知道如何提供支持的“妥善方法”。

在Widget.io这个例子中，与其他模块相比，搜索(Search)功能可能会受益于不一样的语言或数据库选择。若是须要，这么作很是简单。固然，出于其余缘由，咱们已经对它进行了重构！

文化

上面都是技术讨论。那么在文化上呢？

没有任何技术决策是凭空想出来的。所以，在深刻了解精彩的微服务世界以前，先了解一下您的企业。您的组织结构是否能轻松支持微服务架构？根据康威定律，您的成功机率如何？

“通过深思熟虑的早期经验教训可能会抵消康威定律的效果。”

——- @jmckenty

Mel Conway在50年前总结说，任何企业设计的系统都会反映该企业的组织结构。换句话说，若是团队的组织结构不是小型自主团队，那么工程师不可能创造出由小型自主服务组成的软件。这种认识促成了反向康威操纵，即鼓励团队改变其组织结构，来反映他们渴望在应用中看到的架构。

您还应该考虑文化是否准备就绪。微服务提倡以小批量方式频繁进行更改，这种频率通常与传统的季度发布周期相冲突。利用微服务，您不会遇到代码冻结或“一窝蜂式”的代码集成。虽然基于微服务的架构确定能在传统的瀑布式环境中运行，但您没法发挥它的所有优点。

还要考虑如何调配基础架构。关注自助服务和优化价值流的团队通常都采用微服务模式。Pivotal Cloud Foundry等平台帮助团队在几分钟内（而不是几周或几个月）快速部署、测试和优化服务。开发人员只需按一下按钮便可启动实例，这种作法可以推进实验和学习。Buildpack能够自动执行依赖关系管理。这意味着开发人员和运维人员能够专一于交付业务价值。 

即便是你所在行业中的公司也能够从每一年部署四次转型到一个月部署上千次。

最后，咱们针对应用问两个具体问题：

这款应用是否有多个业务全部人？若是系统有多个独立的自主业务全部人，则会有两种不一样变动来源。这种状况可能会致使冲突。利用微服务，您能够实现“独立的生命周期”，让不一样的支持者满意。

这款应用是否由多个团队全部？多个团队开发一个系统的“协调成本”可能很高。所以请为他们定义API。以后，每一个团队均可以使用Spring Cloud Contract构建独立的微服务，也可使用Pact进行消费者驱动的合同

测试。

对于这些问题，若是您有任一项回答是“是”，那么您就应该使用微服务解决方案。

总结

微服务之路的想法是好的。但有很多团队在没有分析需求的状况下就踏上了微服务的浪潮。微服务很是强大，你们都想用！但必定要作出权衡取舍。并且必需要了解应用的业务推进因素，这是无可替代的，由于这对肯定合适的架构方法相当重要。