Microservices指南

的microservices建筑风格一直是去年的热门话题。在最近的O'Reilly软件架构会议华体会体育网页版入口在美国，似乎每次会议都在谈论微服务。足够让所有人的超级扯淡探测器亮起来了。这样做的后果之一是，我们看到团队太急于接受微服务，而没有意识到微服务为他们自己带来了复杂性。这增加了项目的成本和风险——这经常使项目陷入严重的麻烦。

当我听到团队使用microservices架华体会体育网页版入口构，我注意到一个共同的模式。

1. 几乎所有成功的微服务故事都是从一个庞然大物开始的，它变得太大了，然后被拆分了
2. 我听说的几乎所有从零开始构建为微服务系统的系统都以严重的麻烦告终。

这种模式让我的许多同事认为你不应该用微服务开始一个新项目，即使你确定你的应用足够大，值得去做。．

在过去的几个月里，我反复听到这样的说法:获得成功的微服务架构的唯一方法是首先从一个整体开始。华体会体育网页版入口套用Simon Brown的话:如果你不能构建一个结构良好的整体，你凭什么认为你可以构建一组结构良好的微服务?马丁·福勒(Martin Fowler)在这个网站上对这一论点进行了最新的——通常也是非常有说服力的——阐释。因为我有机会对早期的草稿进行评论，所以我有一些时间来思考这个问题。我的确这么做了，尤其是因为我经常发现自己和他的观点一致，而其他一些我通常持有相同观点的人似乎也同意他的观点。

我坚信从一个整体开始通常是错误的做法。

当我和人们谈论使用microservices建筑风格我听到了很多乐观的声音。开发人员喜欢使用更小的单元，并期望获得比单个单元更好的模块化。但是与任何架构决策一样，都有权衡。特别是在微服务方面，对运营人员的影响非常严重，他们现在必须处理一个由小型服务组成的生态系统，而不是一个定义明确的单一整体。因此，如果您不具备某些基本能力，就不应该考虑使用微服务风格。

在EAA的P中我说过“不要分发你的对象”。这个建议是否与我对微服务的兴趣相矛盾?

goto会议邀请我就山姆·纽曼(Sam Newman)的书《从巨石到微服务》(monolths to Microservices)进行采访。这变成了一场关于微服务以及何时使用它们的一般性对话。Sam认为它们的三个主要原因是独立可部署性、数据隔离和反映组织结构。我更怀疑第一个，但考虑到数据和人员是软件开发的复杂部分。华体会登录网址

在过去几年里，基于服务的体系结构已经向更小、更专注的“微”服务转变。华体会体育网页版入口这种方法有很多好处，比如能够独立部署、扩展和维护每个组件，以及跨多个团队并行化开发。然而，一旦引入了这些附加的网络分区，应用于流程内单片应用程序的测试策略就需要重新考虑了。在这里，我们计划讨论一些管理多个独立可部署组件的额外测试复杂性的方法，以及如何在多个团队各自充当不同服务的监护人的情况下保持测试和应用程序的正确性。

由于单片系统变得太大而无法处理，许多企业倾向于将其分解为微服务体系结构样式。这是一段值得的旅程，但并不容易。我们已经了解到，要做好这一点，我们需要从一个简单的服务开始，然后绘制出基于垂直功能的服务，这些垂直功能对业务很重要，而且容易频繁变化。这些服务一开始应该是大型的，最好不要依赖于剩余的整体。我们应该确保迁移的每一步都代表了对整个体系结构的原子性改进。华体会体育网页版入口

好的前端开发是很难的。扩展前端开发以便许多团队可以同时在一个大型而复杂的产品上工作是更加困难的。在本文中，我们将描述最近的一种趋势，即将前端整体分解为许多更小、更易于管理的片段，以及这种体系结构如何提高处理前端代码的团队的有效性和效率。华体会体育网页版入口除了讨论各种好处和成本之外，我们还将介绍一些可用的实现选项，并深入研究演示该技术的完整示例应用程序。

当将大数据块分解为更小的服务时，最困难的部分实际上是分解大数据块数据库中的数据。要提取一个数据丰富的服务，遵循一系列的步骤是很有用的，这些步骤在任何时候都保留一个数据的写-拷贝。这些步骤首先在现有整体中进行逻辑分离:将服务行为分离到单独的模块中，然后将数据分离到单独的表中。这些元素可以单独移动到新的自治服务中。

作为代码的基础设施是一种通过源代码定义计算和网络基础设施的方法，然后可以像对待任何软件系统一样对待源代码。这样的代码可以保存在源代码控制中，以允许审计和ReproducibleBuilds，受测试实践和完整的纪律ContinuousDelivery．这是过去十年来处理经济增长的一种方法CloudComputing平台将成为未来处理计算基础设施的主要方式。

敏捷软件开发华体会登录网址打破了需求分析、测试和开发之间的一些竖井。部署、操作和维护是其他与软件开发过程的其他部分类似分离的活动。华体会登录网址DevOps运动旨在消除这些竖井，鼓励开发和运营之间的协作。

对于软件系统来说，远程调用运行在不同进程中的软件是很常见的，可能是在跨网络的不同机器上。内存中调用和远程调用之间的一个重大区别是，远程调用可能会失败，或者没有响应就挂起，直到达到某个超时限制。更糟糕的是，如果在一个没有响应的供应商上有许多调用者，那么可能会耗尽关键资源，导致多个系统发生级联故障。在他的著作中释放它在美国，迈克尔·尼加德推广了熔断模式，以防止这种灾难性的连锁反应。

断路器的基本原理非常简单。将受保护的函数调用封装在断路器对象中，该对象监视故障。一旦故障达到一定的阈值，断路器跳闸，所有对断路器的进一步调用都返回一个错误，而不进行受保护的调用。通常情况下，如果断路器跳闸，你还需要某种形式的监视器警报。