作者：James Lewis/Martin Folwer
翻译：Zhang Yang

分权治理

集中治理的一个后果是，在单一的标准化技术平台的趋势。经验表明，这种方式是收敛的 - 不是每一个问题都是钉子，同样不是每一个解决方案都是锤子。我们更喜欢使用正确的工具的工作，而整体件应用程序在一定程度上使用不同的语言，并不常见。

当整体的组件分割的到多个服务，在当建立他们的时候，我们有一个选择。你想用Node.js的建立一个简单的报表页面？大胆试试吧。用C ++建立的一个粗糙的近实时的组件？好的。你想替换一个数据库，以适应一个组件的读取行为？我们有技术来重建它。

当然，仅仅因为你可以 做一些事情，并不意味着你应该 -但用这种方式，给你的系统分区域，意味着你有的选。

团队建造微服务时更喜欢另一种不同与趋于标准的方法。不使用一组写在纸上的标准，他们更愿意产生有用的工具，这样其他开发人员可以用它来解决类似的问题。这些工具通常是从实践中产生，并广泛分享，有时候，但不排斥使用内部开源模式。就像现在的Git和github上已经成为版本控制系统的首选一样，开源的做法在内部正变得越来越普遍。

Netflix的是遵循这一理念的组织的一个很好的例子。分享有用的，最重要的，久经考验的代码库，鼓励其他开发人员来解决类似的方式类似的问题，如果需要还允许挑选不同的方法。共享库往往集中在数据存储，进程间通信以及基础设施自动化的常见问题，基础设施自动化后文会详细描述。

对于微服务社区来说，日常管理费用常常不引人瞩目。这并不是说，社会不重视服务约定。恰恰相反，因为往往是更多的注意。这只是他们正在用不同的方法看待管理这些约定方式。微服务常常应用模式 Tolerant Reader和Consumer-Driven Contracts（CDC）。它们帮助服务约定走向独立。将CDC作为构建的一部分，可以增加信心，并提供快速反馈：你的服务是否生效。事实上，我们知道，在澳大利亚的一个团队，他们正在使用CDC构建新的服务。他们用一些简单的工具，它们允许为服务定义约定。这成为自动构建的一部分，甚至在新服务的代码产生之前。服务建立的唯一目的在于它满足了约定–一个优雅的方法来避免“YAGNI”困境[9]。这些技术和工具和他们一起成长，通过降低服务之间的时间耦合，限制对于中央约定管理的需要。

也许分权治理的最高点是构建/运行的这个风气亚马逊。团队负责他们构建的软件的方方面面，包括软件24/7运营。这个级别责任的下放，绝对不是常态，但我们也看到越来越多的企业将责任推给开发团队。Netflix公司是另一个根据这个风气调整的组织[11]。每天晚上在凌晨3点被你的传呼机唤醒，无疑是一个强有力的激励，使得程序员编写代码时要注重质量。这些想法都是关于尽可能地远离传统的集中式管理模式。

分散数据管理

数据分散管理的呈现有许多不同的方式。在最抽象的层次上，这意味着在系统之间世界的概念性模型将是不同的。当整合大型企业时，这是一个常见的问题，销售视图中的客户将不同与售后视图中客户。销售视图中的客户可能不会完整地出现在售后视图中。它们要么有着不同的属性，或者相同的属性却不同的语义（后者更糟）。

这一问题是在不同的应用程序中之间常见的，但也可能发生程序内，特别是当应用程序被分成独立的组件时。一个有用思考方法是的Domain-Driven Design（DDD）设计概念。 DDD把一个复杂的结构分为多个有边界的上下文和映射出它们之间的关系。该过程用于在整体件架构和微服务架构都是有用的，但是服务和上下文的边界之间的自然相关性，有助于澄清，我们之前描述的，加强隔离。

除了关于概念模型中的分散决策，微服务也分散的数据存储的决策。整体件应用程序更喜欢单一逻辑数据库存储数据，但是企业往往更喜欢一个单独的跨一系列应用程序的数据库–这些决策是被供应商版权的商业模式驱动的。微服务愿意让每个服务管理它自己的数据库，要么同一数据库的不同实例，或完全不同的数据库系统–一种称Polyglot Persistence的方法。你可以在整体件中使用多态持续，但它似乎更频繁地和微服务一起工作。

为数据访问分散责任还会影响管理更新。常见的方式是当更新多个资源时，使用事务模型保证一致性。这种方法整体件常常使用。

使用事务有助于保持一致，强加了明显时间的耦合，跨多个服务时会有问题。分布式事务是出了名的难以实现，因此微服务架构强调服务之间的非事务性协作，同时明确认识到，即一致性可能只是最终的一致性和问题需要由补偿运算处理。
选择以这种方式来管理的不一致，对于许多开发团队来说是一个新的挑战，但它是一个常常与商业行为相匹配。通常商家为了快速响应需求，用一些反向处理错误的操作，解决一定程度的不一致。权衡是值得的，只要弥补错误的代价小于获得更高一致性的成本。

基础设施自动化

基础设施的自动化技术已经发展好多年了 - 云、特别是AWS的进化降低构建，部署和运营微服务的操作复杂性。
许多使用微服务构建的产品或系统，正在通过有着广泛持续交付（其前身，持续集成）经验的团队建造出来。团队这样构建软件大量使用的基础设施的自动化技术。在下面所示构建管道。

图5：简单建设管道

因为这不是在持续交付的文章，请只注意这里的主要特性。我们希望获得尽可能多的相信，我们的软件是可以工作的，所以我们运行大量的自动化测试。管道上方的提示的意思是我们自动部署到每个新的环境。

一种整体式应用程序将被构建，测试，并通过这些环境推动相当不错。事实证明，一旦你投资整体式程序的自动化的产品化上，然后部署更多的应用程序，不会可怕到哪去。记住，CD的目的之一是使部署无聊，所以无论是它的一个或三个应用程序，只要它还是无聊的就也没关系[12]。

另一个团队大量使用基础设施自动化的领域，是在产品中管理微服务时。与我们的上述说法，只要部署是无聊的，整体式和微服务之间没有太大相差；相反的是：对操作来说看到的风景是显著不同的。

图6：模块的部署往往不同

备注：
7: We can’t resist mentioning Jim Webber’s statement that ESB stands for “Egregious Spaghetti Box”.
8: Netflix makes the link explicit - until recently referring to their architectural style as fine-grained SOA.
9: “YAGNI” or “You Aren’t Going To Need It” is an XP principle and exhortation to not add features until you know you need them.
10: It’s a little disengenuous of us to claim that monoliths are single language - in order to build systems on todays web, you probably need to know JavaScript and XHTML, CSS, your server side language of choice, SQL and an ORM dialect. Hardly single language, but you know what we mean.
11: Adrian Cockcroft specifically mentions “developer self-service” and “Developers run what they wrote”(sic) in this excellent presentation delivered at Flowcon in November, 2013.
12: We are being a little disengenuous here. Obviously deploying more services, in more complex topologies is more difficult than deploying a single monolith. Fortunately, patterns reduce this complexity - investment in tooling is still a must though.