作者：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.