大企业是如何在实践微服务中成长的

作者：贺思聪 2015-10-28 10:31:27

云计算 在行业中，微服务有着众多不同的定义。某些定义认为它是一种和Unix编程风格类似，以构建很多能够专注于做好一件事情的、微小的、有自治进程的架构风格。某些定义认为它是第一个后DevOps革命的架构。它从DevOps和持续交付中吸取到所有的经验，并且对其进行了优化。

我足够“高”了么?

Martin Fowler描述过当组织在考虑实现微服务架构时，必须要有的一组“能力基线”，但大企业通常有各种理由不太愿意去尝试和成长以达到这样的能力。有很多的文字都提到，在成长之路完成后便能收获微服务架构所能带来的各种好处。这篇文章将描述一个大企业为达到Martin Fowler的能力基线，所经历的挑战和决心。

开篇

在行业中，微服务有着众多不同的定义。某些定义认为它是一种和Unix编程风格类似，以构建很多能够专注于做好一件事情的、微小的、有自治进程的架构风格。某些定义认为它是***个后DevOps革命的架构。它从DevOps和持续交付中吸取到所有的经验，并且对其进行了优化。

我们采用微服务的初衷是为了提供一种能够扩大团队规模的途径。我们从一个单体应用开始，康威定律启迪我们分解这个单体应用。经过这个过程，我们最终变成了很多小而优的团队来进行交付。

团队的结构影响着系统的架构并不是一个新鲜事了。Nygard总结得很到位——“团队的工作分配方式就是架构的初稿”。这种最初对团队伸缩性的需求是将一批***实践带入微服务和持续集成的催化剂。

团队的工作分配方式就是架构的初稿。

拆分单体应用

当我们拆分单体应用时，我们面临的***个挑战是尝试找到系统的接缝或者界限上下文。这种尝试带来了一个非常有意思的副作用，即我们可以通过识别系统中那些比起其他地方更不容易变化的地方，来解耦我们的系统。这和重构代码以让你的代码更经得起时间的考验类似，只不过是在架构层次上罢了。

从单体应用中分割出多个服务是很不简单的。包括创建单独的代码仓库，构建管道和基础设施建设。这些都要消耗时间。因为很多企业都对频繁构建新服务持悲观的态度，我们经常会听到犹豫之声：“如果构建一个服务都用了这么多时间，我们怎么做其他的服务呢?”

我们是在每个迭代中逐步攻克这个问题的。我们改进我们的构建管道、工程的创建、环境设置和部署。这是从微服务架构中所获得的很大一部分益处——它不仅强制性的将质量和成熟度构建进你的软件，而且也包含了开发流程和实践。

步入云端

在改进DevOps***实践的路上，配置环境成了畔脚石。如果需要另一个部门花几周的时间，去配置好一个新的机器来托管你的新服务，你就有麻烦了。幸运的是我们已经准备好步入云端，并且已经在企业层面上准备好了支持云部署所必须的工具链。

即便有这些工具，开发人员也必须开始拥有他们的软件，包括生产环境的部署和支持。封闭的组织有一个趋势是将他们的开发人员与真实地生产环境隔离开。 “谁构建，谁拥有”这个思想非常的重要，它能促进***实践地成熟。亦即，如果开发人员已经对生产环境的稳定性和支持有浓厚的兴趣，那么很有可能是他们构建了这个系统。

谁构建，谁拥有

消费者驱动的契约测试

我们已经拥有了很多已经部署到云端的RESTFul API，并且由团队自己维护这些API。这就意味着团队可以不借助其他人的力量进行独立的开发。不过，我们开始发现依赖的服务在逐渐改变我们的行为。测试和利益相关者开始抱怨系统不稳定——但当我们是单体应用时这根本不是问题。

我们使用集成测试来解决这个问题。服务提供者为其API的消费者维护一组测试，而不是消费者自己为契约写集成测试。这样做有很多的好处：首先，如果服务提供者破坏了契约，它会直接被告知;另外，如果消费者增加了新的测试场景，但这个场景破坏了契约，那么构建也同样会失败。这些考量驱动出更重要的事情，也即团队之间的交流以及尽快的开始这些对话。API始终可以进化，但它会有足够的约束来保证稳定性。

蝴蝶效应

解耦单体应用的另一个副作用是监控的工作量成倍增加。之前你可能在一个应用中只有一个终端(endpoint)，而现在你有很多的服务。为了更好地保证应用正常工作，你必须要为支撑你的服务的基础设置上提供足够的监控。

在单体应用中，如果一个服务调用失败了，我们会清楚地知道哪里出错了。但在一个经常变化的解耦架构中不再成立。当一个服务失败了，真实的失败位置可能是在依赖树上的数个服务。这就意味着平均修复时间(MTTR)会受影响——我们必须要调查受影响的服务，也会调查这个服务所有的依赖。我们使用PRTG监控工具来解决这个问题。PRTG给我们提供了一个高级的仪表盘(dashboard)来图形化系统的不同的部件。

我们发现的另外一种必要地监控是分布式的日志收集。这允许我们从不同的服务器收集日志并且可以做联合查询。我们甚至可以引入相关性ID来改进它。这样分布式的日志允许我们跟踪一个请求的在系统的不同服务中的跳转过程。

展望

当然我们还有一些需要在未来解决的困难问题。包括一些棘手的组织变化，例如将交付与产品对齐而不是和工程对齐，并且使开发人员能够在DevOps的环境中工作。这也包含了更多的环境配置，包括更多的通过Ansible来进行基础设施自动化。尽管还有未来的挑战，我们已经开始收获一些引入微服务先决条件所带来的好处了。你的微服务的旅程是怎样的呢?

原文链接：http://insights.thoughtworkers.org/microservices-how-large-enterprise-grew-doing-it/