这是用户在 2025-1-4 12:02 为 https://martinfowler.com/articles/microservices.html#DecentralizedDataManagement 保存的双语快照页面,由 沉浸式翻译 提供双语支持。了解如何保存?

Microservices  微服务

a definition of this new architectural term
这个新的建筑术语的定义

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
“微服务架构”这个术语如雨后春笋般出现 过去几年描述了一种特殊的软件设计方式 应用程序作为可独立部署的服务套件。尽管 这种建筑风格没有精确的定义,有 组织的某些共同特征 业务能力、自动化部署、智能化 端点以及语言和数据的分散控制。

25 March 2014  2014 年 3 月 25 日


Photo of James Lewis

James Lewis is a Principal Consultant at Thoughtworks and member of the Technology Advisory Board. James' interest in building applications out of small collaborating services stems from a background in integrating enterprise systems at scale. He's built a number of systems using microservices and has been an active participant in the growing community for a couple of years.
James Lewis 是 Thoughtworks 的首席顾问兼技术顾问委员会成员。 James 对利用小型协作服务构建应用程序的兴趣源于大规模集成企业系统的背景。他使用微服务构建了许多系统,并且多年来一直是不断发展的社区的积极参与者。

Photo of Martin Fowler

Martin Fowler is an author, speaker, and general loud-mouth on software development. He's long been puzzled by the problem of how to componentize software systems, having heard more vague claims than he's happy with. He hopes that microservices will live up to the early promise its advocates have found.
Martin Fowler 是一位作家、演说家,也是软件开发领域的知名人士。长期以来,他一直对如何组件化软件系统的问题感到困惑,因为听到的模糊说法比他满意的多。他希望微服务能够兑现其倡导者所发现的早期承诺。


“Microservices” - yet another new term on the crowded streets of software architecture. Although our natural inclination is to pass such things by with a contemptuous glance, this bit of terminology describes a style of software systems that we are finding more and more appealing. We've seen many projects use this style in the last few years, and results so far have been positive, so much so that for many of our colleagues this is becoming the default style for building enterprise applications. Sadly, however, there's not much information that outlines what the microservice style is and how to do it.
“微服务”——软件架构拥挤的街道上的另一个新术语。尽管我们的本能倾向是对这些事情嗤之以鼻,但这个术语描述了一种我们发现越来越有吸引力的软件系统风格。在过去的几年里,我们看到许多项目都使用这种风格,到目前为止,结果是积极的,以至于对于我们的许多同事来说,这正在成为构建企业应用程序的默认风格。然而遗憾的是,没有太多信息来概述微服务风格是什么以及如何做到这一点。

In short, the microservice architectural style 1 is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
简而言之,微服务架构风格1是一种将单个应用程序开发为一组小型服务的方法,每个服务都在自己的进程中运行并与轻量级机制(通常是 HTTP 资源 API)进行通信。这些服务围绕业务功能构建,并可通过全自动部署机制独立部署。这些服务的集中管理是最低限度的,这些服务可能用不同的编程语言编写并使用不同的数据存储技术。

1: The term “microservice” was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as “fine grained SOA” was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Daniel Terhorst-North, Evan Botcher and Graham Tackley.
1: 在软件研讨会上讨论了“微服务”一词 2011 年 5 月,威尼斯附近的建筑师们描述了 参与者认为这是一种共同的建筑风格 他们最近一直在探索。 2012 年 5 月,同一小组决定 “微服务”是最合适的名称。詹姆斯介绍了其中一些 2012 年 3 月在克拉科夫 33rd Degree 举办的案例研究 微服务 - Java,Unix 方式,正如 Fred George所说 同时。 Netflix 的 Adrian Cockcroft 描述了这一点 “细粒度 SOA”方法开创了 Web 风格 规模与本文中提到的许多其他人一样 - Joe 沃尔恩斯、丹尼尔·特霍斯特-诺斯、埃文·博彻和 格雷厄姆·泰克利.

To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable2. Any changes to the system involve building and deploying a new version of the server-side application.
为了开始解释微服务风格,将其与整体风格进行比较是有用的:作为单个单元构建的整体应用程序。企业应用程序通常由三个主要部分构建: 客户端用户界面(由 HTML 页面和在用户计算机上的浏览器中运行的 JavaScript 组成) 数据库(由插入到公共且通常是关系数据库管理中的许多表组成)系统)和服务器端应用程序。服务器端应用程序将处理 HTTP 请求、执行域逻辑、从数据库检索和更新数据,以及选择和填充要发送到浏览器的 HTML 视图。该服务器端应用程序是一个整体- 单个逻辑可执行文件2 。对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。

2: The term monolith has been in use by the Unix community for some time. It appears in The Art of Unix Programming to describe systems that get too big.

Such a monolithic server is a natural way to approach building such a system. All your logic for handling a request runs in a single process, allowing you to use the basic features of your language to divide up the application into classes, functions, and namespaces. With some care, you can run and test the application on a developer's laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. You can horizontally scale the monolith by running many instances behind a load-balancer.
这样的整体服务器是构建这样的系统的自然方法。处理请求的所有逻辑都在单个进程中运行,允许您使用语言的基本功能将应用程序划分为类、函数和命名空间。只要小心一点,您就可以在开发人员的笔记本电脑上运行和测试应用程序,并使用部署管道来确保更改得到正确的测试并将其部署到生产中。您可以通过在负载均衡器后面运行许多实例来水平扩展单体应用。

Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.
单体应用程序可能会取得成功,但越来越多的人对它们感到沮丧 - 特别是随着越来越多的应用程序部署到云中。变更周期是紧密相连的——对应用程序的一小部分进行的更改需要重建和部署整个整体。随着时间的推移,通常很难保持良好的模块化结构,从而使得保持应该只影响该模块中的一个模块的更改变得更加困难。扩展需要扩展整个应用程序,而不是扩展需要更多资源的部分。

Figure 1: Monoliths and Microservices
图 1:整体架构和微服务

These frustrations have led to the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .
这些挫折催生了微服务架构风格:将应用程序构建为服务套件。除了服务可以独立部署和扩展之外,每个服务还提供了严格的模块边界,甚至允许使用不同的编程语言编写不同的服务。它们也可以由不同的团队管理。

We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it.
我们并不认为微服务风格是新颖的或创新的,它的根源至少可以追溯到 Unix 的设计原则。但我们确实认为没有足够多的人考虑微服务架构,并且如果他们使用它,许多软件开发会变得更好。

Characteristics of a Microservice Architecture
微服务架构的特点

We cannot say there is a formal definition of the microservices architectural style, but we can attempt to describe what we see as common characteristics for architectures that fit the label. As with any definition that outlines common characteristics, not all microservice architectures have all the characteristics, but we do expect that most microservice architectures exhibit most characteristics. While we authors have been active members of this rather loose community, our intention is to attempt a description of what we see in our own work and in similar efforts by teams we know of. In particular we are not laying down some definition to conform to.
我们不能说微服务架构风格有一个正式的定义,但我们可以尝试描述我们所认为的适合该标签的架构的共同特征。与任何概述共同特征的定义一样,并非所有微服务架构都具有所有特征,但我们确实期望大多数微服务架构表现出大多数特征。虽然我们作者一直是这个相当松散的社区的活跃成员,但我们的目的是尝试描述我们在自己的工作以及我们所知道的团队的类似努力中看到的内容。特别是我们没有制定一些需要遵守的定义。

Componentization via Services
通过服务进行组件化

For as long as we've been involved in the software industry, there's been a desire to build systems by plugging together components, much in the way we see things are made in the physical world. During the last couple of decades we've seen considerable progress with large compendiums of common libraries that are part of most language platforms.
自从我们涉足软件行业以来,就一直渴望通过将组件插入在一起来构建系统,就像我们在物理世界中看到的事物的制造方式一样。在过去的几十年里,我们看到作为大多数语言平台一部分的大型公共库纲要取得了长足的进步。

When talking about components we run into the difficult definition of what makes a component. Our definition is that a component is a unit of software that is independently replaceable and upgradeable.
当谈论组件时,我们会遇到组件的复杂定义。我们的定义是一个 组件是可独立替换和升级的软件单元。

Microservice architectures will use libraries, but their primary way of componentizing their own software is by breaking down into services. We define libraries as components that are linked into a program and called using in-memory function calls, while services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. (This is a different concept to that of a service object in many OO programs 3.)
微服务架构将使用库,但它们组件化自己软件的主要方式是分解为服务。我们定义 作为链接到程序并使用调用的组件 内存中函数调用,而服务是进程外组件,它们与 Web 服务请求或远程过程调用等机制进行通信。 (这与许多 OO 程序中的服务对象的概念不同3 。)

3: Many object-oriented designers, including ourselves, use the term service object in the Domain-Driven Design sense for an object that carries out a significant process that isn't tied to an entity. This is a different concept to how we're using “service” in this article. Sadly the term service has both meanings and we have to live with the polyseme.

One main reason for using services as components (rather than libraries) is that services are independently deployable. If you have an application 4 that consists of a multiple libraries in a single process, a change to any single component results in having to redeploy the entire application. But if that application is decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed. That's not an absolute, some changes will change service interfaces resulting in some coordination, but the aim of a good microservice architecture is to minimize these through cohesive service boundaries and evolution mechanisms in the service contracts.
使用服务作为组件(而不是库)的主要原因之一是服务是可独立部署的。如果您的应用程序4在单个进程中包含多个库,则对任何单个组件的更改都将导致必须重新部署整个应用程序。但是,如果该应用程序被分解为多个服务,则您可以预期许多单个服务更改只需要重新部署该服务。这并不是绝对的,一些变化会改变服务接口,从而导致一些协调,但良好的微服务架构的目标是通过服务契约中的内聚服务边界和演化机制来最小化这些变化。

4: We consider an application to be a social construction that binds together a code base, group of functionality, and body of funding.

Another consequence of using services as components is a more explicit component interface. Most languages do not have a good mechanism for defining an explicit Published Interface. Often it's only documentation and discipline that prevents clients breaking a component's encapsulation, leading to overly-tight coupling between components. Services make it easier to avoid this by using explicit remote call mechanisms.
使用服务作为组件的另一个结果是更明确的组件接口。大多数语言没有良好的机制来定义显式的已发布接口。通常,只有文档和规则才能防止客户端破坏组件的封装,从而导致组件之间的耦合过于紧密。通过使用显式远程调用机制,服务可以更轻松地避免这种情况。

Using services like this does have downsides. Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained, which is often more awkward to use. If you need to change the allocation of responsibilities between components, such movements of behavior are harder to do when you're crossing process boundaries.
使用这样的服务确实有缺点。远程调用比进程内调用更昂贵,因此远程 API 需要更粗粒度,这通常更难以使用。如果您需要更改组件之间的职责分配,那么当您跨越流程边界时,这种行为移动就更难做到。

At a first approximation, we can observe that services map to runtime processes, but that is only a first approximation. A service may consist of multiple processes that will always be developed and deployed together, such as an application process and a database that's only used by that service.
在第一个近似值中,我们可以观察到服务映射到运行时进程,但这只是第一个近似值。服务可能由始终一起开发和部署的多个进程组成,例如应用程序进程和仅由该服务使用的数据库。

Organized around Business Capabilities
围绕业务能力组织

When looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval. A smart team will optimise around this and plump for the lesser of two evils - just force the logic into whichever application they have access to. Logic everywhere in other words. This is an example of Conway's Law in action.
当希望将大型应用程序拆分为多个部分时,管理层通常会关注技术层,从而产生 UI 团队、服务器端逻辑团队和数据库团队。当团队按照这些原则分开时,即使是简单的更改也可能导致跨团队项目需要时间和预算批准。聪明的团队将围绕这一点进行优化,并两害相权取其轻——只需将逻辑强加到他们有权访问的任何应用程序中即可。换句话说,逻辑无处不在。这是康威定律发挥作用的一个例子。

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
任何设计系统(广义定义)的组织都会产生其结构是组织通信结构的副本的设计。

-- Melvin Conway, 1968  ——梅尔文·康威,1968

Figure 2: Conway's Law in action
图 2:康威定律的应用

The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.
微服务的划分方式不同, 分成围绕以下组织的服务 业务能力。此类服务采用该业务领域的软件的广泛堆栈实现,包括用户界面、持久存储和任何外部协作。因此,团队是跨职能的,包括开发所需的全方位技能:用户体验、数据库和项目管理。

Figure 3: Service boundaries reinforced by team boundaries
图 3:团队边界强化了服务边界

One company organised in this way is www.comparethemarket.com. Cross functional teams are responsible for building and operating each product and each product is split out into a number of individual services communicating via a message bus.
www.comparethemarket.com是一家以这种方式组织的公司。跨职能团队负责构建和运营每个产品,每个产品都分为许多通过消息总线进行通信的单独服务。

Large monolithic applications can always be modularized around business capabilities too, although that's not the common case. Certainly we would urge a large team building a monolithic application to divide itself along business lines. The main issue we have seen here, is that they tend to be organised around too many contexts. If the monolith spans many of these modular boundaries it can be difficult for individual members of a team to fit them into their short-term memory. Additionally we see that the modular lines require a great deal of discipline to enforce. The necessarily more explicit separation required by service components makes it easier to keep the team boundaries clear.
大型单体应用程序也始终可以围绕业务功能进行模块化,尽管这并不常见。当然,我们会敦促构建单一应用程序的大型团队按照业务线进行划分。我们在这里看到的主要问题是它们往往围绕太多的上下文进行组织。如果整体跨越了许多这样的模块边界,那么团队的各个成员就很难将它们放入他们的短期记忆中。此外,我们发现模块化生产线需要严格的纪律来执行。服务组件所需的必然更明确的分离使得更容易保持团队边界清晰。

Products not Projects  产品而非项目

Most application development efforts that we see use a project model: where the aim is to deliver some piece of software which is then considered to be completed. On completion the software is handed over to a maintenance organization and the project team that built it is disbanded.
我们看到的大多数应用程序开发工作都使用项目模型:其目标是交付一些软件,然后将其视为已完成。完成后,该软件将移交给维护组织,并且构建该软件的项目团队将被解散。

Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon's notion of “you build, you run it” where a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden.
微服务支持者倾向于避免这种模型,而更喜欢团队应该在产品的整个生命周期中拥有产品的概念。对此的一个常见灵感来自亚马逊的“你构建,你运行”的理念,其中开发团队对生产中的软件承担全部责任。这使开发人员能够日常接触他们的软件在生产中的行为方式,并增加与用户的联系,因为他们必须承担至少一些支持负担。

The product mentality, ties in with the linkage to business capabilities. Rather than looking at the software as a set of functionality to be completed, there is an on-going relationship where the question is how can software assist its users to enhance the business capability.
产品心态与业务能力联系在一起。不是将软件视为一组需要完成的功能,而是存在一种持续的关系,问题是软件如何帮助其用户增强业务能力。

There's no reason why this same approach can't be taken with monolithic applications, but the smaller granularity of services can make it easier to create the personal relationships between service developers and their users.
没有理由不能对单体应用程序采用相同的方法,但是较小的服务粒度可以更轻松地在服务开发人员及其用户之间创建个人关系。

Smart endpoints and dumb pipes
智能端点和哑管道

When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.
在不同流程之间构建通信结构时,我们看到许多产品和方法都强调将重要的智能融入通信机制本身。企业服务总线 (ESB) 就是一个很好的例子,其中 ESB 产品通常包括用于消息路由、编排、转换和应用业务规则的复杂设施。

The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.
微服务社区青睐另一种方法: 智能端点和哑管道。从微服务构建的应用程序旨在尽可能解耦和内聚 - 它们拥有自己的域逻辑,并且更多地充当经典 Unix 意义上的过滤器 - 接收请求,应用适当的逻辑并生成响应。这些是使用简单的 RESTish 协议来编排的,而不是使用 WS-Choreography 或 BPEL 等复杂协议或通过中央工具进行编排。

The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging7. The best expression of the first is
最常用的两种协议是使用资源 API 的 HTTP 请求-响应和轻量级消息传递7 。第一个的最佳表达是

7: At extremes of scale, organisations often move to binary protocols - protobufs for example. Systems using these still exhibit the characteristic of smart endpoints, dumb pipes - and trade off transparency for scale. Most web properties and certainly the vast majority of enterprises don't need to make this tradeoff - transparency can be a big win.

Be of the web, not behind the web
属于网络,而非网络背后

-- Ian Robinson
——伊恩·罗宾逊

Microservice teams use the principles and protocols that the world wide web (and to a large extent, Unix) is built on. Often used resources can be cached with very little effort on the part of developers or operations folk.
微服务团队使用万维网(以及很大程度上 Unix)构建基础的原则和协议。开发人员或操作人员只需付出很少的努力就可以缓存经常使用的资源。

The second approach in common use is messaging over a lightweight message bus. The infrastructure chosen is typically dumb (dumb as in acts as a message router only) - simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric - the smarts still live in the end points that are producing and consuming messages; in the services.
第二种常用的方法是通过轻量级消息总线进行消息传递。所选择的基础设施通常是愚蠢的(愚蠢的,仅充当消息路由器) - 简单的实现,例如 RabbitMQ 或 ZeroMQ,除了提供可靠的异步结构外,并没有做更多的事情 - 智能仍然存在于正在生产和发布的端点中。消费消息;在服务中。

In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don't perform well. Instead you need to replace the fine-grained communication with a coarser -grained approach.
在整体中,组件在进程内执行,它们之间的通信是通过方法调用或函数调用。将整体架构转变为微服务的最大问题在于改变通信模式。从内存中方法调用到 RPC 的简单转换会导致通信繁琐,性能不佳。相反,您需要用粗粒度的方法替换细粒度的通信。

Decentralized Governance  去中心化治理

One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer. We prefer using the right tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn't that common.
集中治理的后果之一是单一技术平台上的标准化趋势。经验表明,这种方法是有局限性的——并不是每个问题都是钉子,也不是每个解决方案都是锤子。我们更喜欢使用正确的工具来完成工作,虽然单体应用程序可以在一定程度上利用不同的语言,但这并不常见。

Splitting the monolith's components out into services we have a choice when building each of them. You want to use Node.js to standup a simple reports page? Go for it. C++ for a particularly gnarly near-real-time component? Fine. You want to swap in a different flavour of database that better suits the read behaviour of one component? We have the technology to rebuild him.
将整体组件拆分为服务,我们在构建每个服务时都有选择。您想使用 Node.js 建立一个简单的报告页面吗?大胆试试吧。 C++ 用于特别粗糙的近实时组件?美好的。您想更换一种更适合某个组件读取行为的不同风格的数据库吗?我们有技术来重建他。

Of course, just because you can do something, doesn't mean you should - but partitioning your system in this way means you have the option.
当然,仅仅因为您可以做某事,并不意味着您应该这样做- 但以这种方式对系统进行分区意味着您可以选择。

Teams building microservices prefer a different approach to standards too. Rather than use a set of defined standards written down somewhere on paper they prefer the idea of producing useful tools that other developers can use to solve similar problems to the ones they are facing. These tools are usually harvested from implementations and shared with a wider group, sometimes, but not exclusively using an internal open source model. Now that git and github have become the de facto version control system of choice, open source practices are becoming more and more common in-house .
构建微服务的团队也更喜欢采用不同的标准方法。他们不喜欢使用写在纸上的一组定义的标准,而是更喜欢生产有用的工具,其他开发人员可以使用这些工具来解决与他们面临的类似问题。这些工具通常是从实现中获取的,并与更广泛的群体共享,有时但不完全使用内部开源模型。现在 git 和 github 已经成为事实上的版本控制系统选择,开源实践在内部变得越来越普遍。

Netflix is a good example of an organisation that follows this philosophy. Sharing useful and, above all, battle-tested code as libraries encourages other developers to solve similar problems in similar ways yet leaves the door open to picking a different approach if required. Shared libraries tend to be focused on common problems of data storage, inter-process communication and as we discuss further below, infrastructure automation.
Netflix 是遵循这一理念的组织的一个很好的例子。将有用且最重要的是经过实战检验的代码作为库共享,可以鼓励其他开发人员以类似的方式解决类似的问题,但也为在需要时选择不同的方法留下了余地。共享库往往关注数据存储、进程间通信以及我们下面进一步讨论的基础设施自动化的常见问题。

For the microservice community, overheads are particularly unattractive. That isn't to say that the community doesn't value service contracts. Quite the opposite, since there tend to be many more of them. It's just that they are looking at different ways of managing those contracts. Patterns like Tolerant Reader and Consumer-Driven Contracts are often applied to microservices. These aid service contracts in evolving independently. Executing consumer driven contracts as part of your build increases confidence and provides fast feedback on whether your services are functioning. Indeed we know of a team in Australia who drive the build of new services with consumer driven contracts. They use simple tools that allow them to define the contract for a service. This becomes part of the automated build before code for the new service is even written. The service is then built out only to the point where it satisfies the contract - an elegant approach to avoid the 'YAGNI'9 dilemma when building new software. These techniques and the tooling growing up around them, limit the need for central contract management by decreasing the temporal coupling between services.
对于微服务社区来说,开销尤其重要 没有吸引力。这并不是说社区不 价值服务合同。恰恰相反,因为有倾向 还有更多。只是他们在看 管理这些合同的不同方式。图案如 宽容的读者消费者驱动的契约通常应用于微服务。这些有助于服务合同的独立发展。将执行消费者驱动的合同作为构建的一部分可以增强信心,并提供有关服务是否正常运行的快速反馈。事实上,我们知道澳大利亚有一个团队通过消费者驱动的合同来推动新服务的构建。他们使用简单的工具来定义服务合同。在编写新服务的代码之前,这就成为自动构建的一部分。然后,服务仅构建到满足合同的程度——这是一种避免构建新软件时出现“YAGNI” 9困境的优雅方法。这些技术和围绕它们发展起来的工具通过减少服务之间的时间耦合来限制对中央合同管理的需求。

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.

Perhaps the apogee of decentralised governance is the build it / run it ethos popularised by Amazon. Teams are responsible for all aspects of the software they build including operating the software 24/7. Devolution of this level of responsibility is definitely not the norm but we do see more and more companies pushing responsibility to the development teams. Netflix is another organisation that has adopted this ethos10. Being woken up at 3am every night by your pager is certainly a powerful incentive to focus on quality when writing your code. These ideas are about as far away from the traditional centralized governance model as it is possible to be.
也许去中心化治理的顶峰是亚马逊所推广的“构建/运行”精神。团队负责他们构建的软件的各个方面,包括 24/7 操作软件。这种级别的责任下放绝对不是常态,但我们确实看到越来越多的公司将责任推给开发团队。 Netflix 是另一个采用这种精神的组织10 。每天凌晨 3 点被寻呼机叫醒无疑是在编写代码时关注质量的强大动力。这些想法与传统的中心化治理模式相差甚远。

10: Adrian Cockcroft specifically mentions “developer self-service” and “Developers run what they wrote”(sic) in this excellent presentation delivered at Flowcon in November, 2013.

Decentralized Data Management
分散数据管理

Decentralization of data management presents in a number of different ways. At the most abstract level, it means that the conceptual model of the world will differ between systems. This is a common issue when integrating across a large enterprise, the sales view of a customer will differ from the support view. Some things that are called customers in the sales view may not appear at all in the support view. Those that do may have different attributes and (worse) common attributes with subtly different semantics.
数据管理的分散化以多种不同的方式呈现。在最抽象的层面上,这意味着世界的概念模型在系统之间会有所不同。这是跨大型企业集成时的常见问题,客户的销售视图与支持视图会有所不同。一些在销售视图中称为客户的事物可能根本不会出现在支持视图中。那些确实的可能具有不同的属性和(更糟糕的)具有细微不同语义的共同属性。

This issue is common between applications, but can also occur within applications, particular when that application is divided into separate components. A useful way of thinking about this is the Domain-Driven Design notion of Bounded Context. DDD divides a complex domain up into multiple bounded contexts and maps out the relationships between them. This process is useful for both monolithic and microservice architectures, but there is a natural correlation between service and context boundaries that helps clarify, and as we describe in the section on business capabilities, reinforce the separations.
此问题在应用程序之间很常见,但也可能发生在应用程序内部,特别是当 应用程序被分为单独的组件。一个有用的方法 思考这个问题的领域驱动设计概念 有界上下文。 DDD 将复杂域划分为多个有界上下文,并映射出它们之间的关系。此过程对于整体架构和微服务架构都很有用,但是服务和上下文边界之间存在天然的相关性,这有助于澄清,并且正如我们在业务功能部分中所描述的那样,加强了分离。

As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions. While monolithic applications prefer a single logical database for persistant data, enterprises often prefer a single database across a range of applications - many of these decisions driven through vendor's commercial models around licensing. Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence. You can use polyglot persistence in a monolith, but it appears more frequently with microservices.
除了分散有关概念模型的决策之外,微服务还分散了数据存储决策。虽然整体应用程序更喜欢使用单个逻辑数据库来存储持久数据,但企业通常更喜欢跨一系列应用程序使用单个数据库 - 其中许多决策是通过供应商围绕许可的商业模型驱动的。微服务更喜欢让每个服务管理自己的数据库,可以是同一数据库技术的不同实例,也可以是完全不同的数据库系统 - 这种方法称为多语言持久性。您可以在单体应用中使用多语言持久性,但它在微服务中出现得更频繁。

Decentralizing responsibility for data across microservices has implications for managing updates. The common approach to dealing with updates has been to use transactions to guarantee consistency when updating multiple resources. This approach is often used within monoliths.
跨微服务分散数据责任对于管理更新具有影响。处理更新的常见方法是使用事务来保证更新多个资源时的一致性。这种方法通常在单体应用中使用。

Using transactions like this helps with consistency, but imposes significant temporal coupling, which is problematic across multiple services. Distributed transactions are notoriously difficult to implement and as a consequence microservice architectures emphasize transactionless coordination between services, with explicit recognition that consistency may only be eventual consistency and problems are dealt with by compensating operations.
使用这样的事务有助于提高一致性,但会带来严重的时间耦合,这在多个服务中会出现问题。众所周知,分布式事务很难实现,因此微服务架构强调服务之间的无事务协调,并明确认识到一致性可能只是最终的一致性,通过补偿操作来解决问题。

Choosing to manage inconsistencies in this way is a new challenge for many development teams, but it is one that often matches business practice. Often businesses handle a degree of inconsistency in order to respond quickly to demand, while having some kind of reversal process to deal with mistakes. The trade-off is worth it as long as the cost of fixing mistakes is less than the cost of lost business under greater consistency.
选择以这种方式管理不一致对于许多开发团队来说是一项新挑战,但它通常符合业务实践。通常,企业会处理一定程度的不一致,以便快速响应需求,同时采用某种逆转流程来处理错误。只要修复错误的成本低于在更高一致性下失去业务的成本,这种权衡就是值得的。

Infrastructure Automation
基础设施自动化

Infrastructure automation techniques have evolved enormously over the last few years - the evolution of the cloud and AWS in particular has reduced the operational complexity of building, deploying and operating microservices.
基础设施自动化技术在过去几年中取得了巨大发展 - 尤其是云和 AWS 的发展降低了构建、部署和操作微服务的操作复杂性。

Many of the products or systems being build with microservices are being built by teams with extensive experience of Continuous Delivery and it's precursor, Continuous Integration. Teams building software this way make extensive use of infrastructure automation techniques. This is illustrated in the build pipeline shown below.
许多使用微服务构建的产品或系统都是由在持续交付及其前身持续集成方面拥有丰富经验的团队构建的。以这种方式构建软件的团队广泛使用基础设施自动化技术。如下所示的构建管道对此进行了说明。

Figure 5: basic build pipeline
图 5:基本构建管道

Since this isn't an article on Continuous Delivery we will call attention to just a couple of key features here. We want as much confidence as possible that our software is working, so we run lots of automated tests. Promotion of working software 'up' the pipeline means we automate deployment to each new environment.
由于这不是一篇关于持续交付的文章,我们在此仅提请注意几个关键功能。我们希望尽可能相信我们的软件正在运行,因此我们运行了大量的自动化测试。工作软件的推广意味着我们可以实现部署自动化 到每一个新的环境。

A monolithic application will be built, tested and pushed through these environments quite happlily. It turns out that once you have invested in automating the path to production for a monolith, then deploying more applications doesn't seem so scary any more. Remember, one of the aims of CD is to make deployment boring, so whether its one or three applications, as long as its still boring it doesn't matter11.
一个整体应用程序将非常愉快地在这些环境中构建、测试和推送。事实证明,一旦您投资了整体生产路径的自动化,那么部署更多应用程序似乎不再那么可怕了。请记住,CD 的目标之一是让部署变得无聊,因此无论是一个还是三个应用程序,只要它仍然无聊就没关系11

11: 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.

Another area where we see teams using extensive infrastructure automation is when managing microservices in production. In contrast to our assertion above that as long as deployment is boring there isn't that much difference between monoliths and microservices, the operational landscape for each can be strikingly different.
我们看到团队使用广泛的基础设施自动化的另一个领域是管理生产中的微服务。与我们上面的断言相反,只要部署很无聊,单体应用和微服务之间就没有太大区别,但两者的操作环境可能会截然不同。

Figure 6: Module deployment often differs
图 6:模块部署通常有所不同

Design for failure  为失败而设计

A consequence of using services as components, is that applications need to be designed so that they can tolerate the failure of services. Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible. This is a disadvantage compared to a monolithic design as it introduces additional complexity to handle it. The consequence is that microservice teams constantly reflect on how service failures affect the user experience. Netflix's Simian Army induces failures of services and even datacenters during the working day to test both the application's resilience and monitoring.
使用服务作为组件的结果是应用程序需要被设计为能够容忍服务的故障。任何服务调用都可能因供应商不可用而失败,客户端必须尽可能优雅地对此做出响应。与单片设计相比,这是一个缺点,因为它增加了处理它的复杂性。结果是微服务团队不断反思服务故障如何影响用户体验。 Netflix 的《猿猴军团》 导致服务甚至数据中心故障 一个工作日来测试应用程序的弹性和 监控。

This kind of automated testing in production would be enough to give most operation groups the kind of shivers usually preceding a week off work. This isn't to say that monolithic architectural styles aren't capable of sophisticated monitoring setups - it's just less common in our experience.
这种生产中的自动化测试足以让大多数运营团队在下班前一周感到不寒而栗。这并不是说整体架构风格不能进行复杂的监控设置——只是在我们的经验中这种情况不太常见。

Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service. Microservice applications put a lot of emphasis on real-time monitoring of the application, checking both architectural elements (how many requests per second is the database getting) and business relevant metrics (such as how many orders per minute are received). Semantic monitoring can provide an early warning system of something going wrong that triggers development teams to follow up and investigate.
由于服务随时可能发生故障,因此能够快速检测故障并在可能的情况下自动恢复服务非常重要。微服务应用程序非常重视应用程序的实时监控,检查架构元素(数据库每秒获取多少个请求)和业务相关指标(例如每分钟收到多少订单)。语义监控可以提供出现问题的早期预警系统,从而触发开发团队进行跟进和调查。

This is particularly important to a microservices architecture because the microservice preference towards choreography and event collaboration leads to emergent behavior. While many pundits praise the value of serendipitous emergence, the truth is that emergent behavior can sometimes be a bad thing. Monitoring is vital to spot bad emergent behavior quickly so it can be fixed.
这对于微服务架构尤其重要,因为微服务偏好编排和事件协作 导致紧急行为。尽管许多专家称赞 偶然出现的价值,事实是,突然出现 行为有时可能是一件坏事。监控至关重要 快速发现不良的紧急行为,以便予以修复。

Monoliths can be built to be as transparent as a microservice - in fact, they should be. The difference is that you absolutely need to know when services running in different processes are disconnected. With libraries within the same process this kind of transparency is less likely to be useful.
单体应用可以构建得像微服务一样透明——事实上,它们也应该如此。不同之处在于,您绝对需要知道不同进程中运行的服务何时断开连接。对于同一流程中的库来说,这种透明度不太可能有用。

Microservice teams would expect to see sophisticated monitoring and logging setups for each individual service such as dashboards showing up/down status and a variety of operational and business relevant metrics. Details on circuit breaker status, current throughput and latency are other examples we often encounter in the wild.
微服务团队希望看到每个单独服务的复杂监控和日志记录设置,例如显示启动/关闭状态以及各种运营和业务相关指标的仪表板。有关断路器状态、当前吞吐量和延迟的详细信息是我们在野外经常遇到的其他示例。

Evolutionary Design  进化设计

Microservice practitioners, usually have come from an evolutionary design background and see service decomposition as a further tool to enable application developers to control changes in their application without slowing down change. Change control doesn't necessarily mean change reduction - with the right attitudes and tools you can make frequent, fast, and well-controlled changes to software.
微服务从业者通常具有渐进式设计背景,并将服务分解视为一种进一步的工具,使应用程序开发人员能够控制应用程序中的更改,而不会减慢更改速度。变更控制并不一定意味着减少变更——只要有正确的态度和工具,您就可以对软件进行频繁、快速和良好控制的变更。

Whenever you try to break a software system into components, you're faced with the decision of how to divide up the pieces - what are the principles on which we decide to slice up our application? The key property of a component is the notion of independent replacement and upgradeability12 - which implies we look for points where we can imagine rewriting a component without affecting its collaborators. Indeed many microservice groups take this further by explicitly expecting many services to be scrapped rather than evolved in the longer term.
每当您尝试将软件系统分解为组件时,您都会面临如何划分各个部分的决定 - 我们决定划分应用程序的原则是什么?组件的关键属性是独立替换和可升级性的概念12 - 这意味着我们寻找可以想象重写组件而不影响其协作者的点。事实上,许多微服务团体更进一步,明确期望从长远来看许多服务将被废弃而不是发展。

12: In fact, Daniel Terhorst-North refers to this style as Replaceable Component Architecture rather than microservices. Since this seems to talk to a subset of the characteristics we prefer the latter.

The Guardian website is a good example of an application that was designed and built as a monolith, but has been evolving in a microservice direction. The monolith still is the core of the website, but they prefer to add new features by building microservices that use the monolith's API. This approach is particularly handy for features that are inherently temporary, such as specialized pages to handle a sporting event. Such a part of the website can quickly be put together using rapid development languages, and removed once the event is over. We've seen similar approaches at a financial institution where new services are added for a market opportunity and discarded after a few months or even weeks.
Guardian 网站是一个很好的应用程序示例,该应用程序是作为整体设计和构建的,但一直在向微服务方向发展。整体架构仍然是网站的核心,但他们更喜欢通过构建使用整体架构 API 的微服务来添加新功能。这种方法对于本质上是临时的功能特别方便,例如处理体育赛事的专用页面。网站的此类部分可以使用快速开发语言快速组合在一起,并在活动结束后删除。我们在一家金融机构中看到过类似的方法,为了获得市场机会而添加新服务,但在几个月甚至几周后就被丢弃。

This emphasis on replaceability is a special case of a more general principle of modular design, which is to drive modularity through the pattern of change 13. You want to keep things that change at the same time in the same module. Parts of a system that change rarely should be in different services to those that are currently undergoing lots of churn. If you find yourself repeatedly changing two services together, that's a sign that they should be merged.
这种对可替换性的强调是模块化设计更普遍原则的一个特例,即通过变更模式来驱动模块化13 。您希望将同时更改的内容保留在同一模块中。系统中很少变化的部分应该与当前正在经历大量变动的部分处于不同的服务中。如果您发现自己反复更改两项服务,则表明它们应该合并。

13: Kent Beck highlights this as one his design principles in Implementation Patterns.

Putting components into services adds an opportunity for more granular release planning. With a monolith any changes require a full build and deployment of the entire application. With microservices, however, you only need to redeploy the service(s) you modified. This can simplify and speed up the release process. The downside is that you have to worry about changes to one service breaking its consumers. The traditional integration approach is to try to deal with this problem using versioning, but the preference in the microservice world is to only use versioning as a last resort. We can avoid a lot of versioning by designing services to be as tolerant as possible to changes in their suppliers.
将组件放入服务中可以增加更精细的发布规划的机会。对于整体应用程序,任何更改都需要完整构建和部署整个应用程序。然而,使用微服务,您只需要重新部署您修改的服务。这可以简化并加速发布过程。缺点是您必须担心一项服务的更改会破坏其消费者。传统的集成方法是尝试使用版本控制来解决这个问题,但微服务世界中的偏好是仅将版本控制作为最后的手段。我们可以通过将服务设计为尽可能容忍供应商的变更来避免大量版本控制。

Are Microservices the Future?
微服务是未来吗?

Our main aim in writing this article is to explain the major ideas and principles of microservices. By taking the time to do this we clearly think that the microservices architectural style is an important idea - one worth serious consideration for enterprise applications. We have recently built several systems using the style and know of others who have used and favor this approach.
我们写这篇文章的主要目的是解释微服务的主要思想和原理。通过花时间来做这件事,我们清楚地认为微服务架构风格是一个重要的想法——对于企业应用程序来说值得认真考虑。我们最近使用这种风格构建了几个系统,并且了解其他人已经使用并喜欢这种方法。

Those we know about who are in some way pioneering the architectural style include Amazon, Netflix, The Guardian, the UK Government Digital Service, realestate.com.au, Forward and comparethemarket.com. The conference circuit in 2013 was full of examples of companies that are moving to something that would class as microservices - including Travis CI. In addition there are plenty of organizations that have long been doing what we would class as microservices, but without ever using the name. (Often this is labelled as SOA - although, as we've said, SOA comes in many contradictory forms. 14)
据我们所知,在某种程度上开创了这种架构风格的公司包括亚马逊、Netflix、卫报英国政府数字服务realestate.com.au 、Forward 和comparethemarket.com 。 2013 年的巡回会议充满了正在转向微服务的公司的例子 - 包括 Travis CI。此外,有很多组织长期以来一直在做我们称之为微服务的事情,但从未使用过这个名称。 (通常这被标记为 SOA - 尽管正如我们所说,SOA 有许多相互矛盾的形式。14

14: And SOA is hardly the root of this history. I remember people saying “we've been doing this for years” when the SOA term appeared at the beginning of the century. One argument was that this style sees its roots as the way COBOL programs communicated via data files in the earliest days of enterprise computing. In another direction, one could argue that microservices are the same thing as the Erlang programming model, but applied to an enterprise application context.

Despite these positive experiences, however, we aren't arguing that we are certain that microservices are the future direction for software architectures. While our experiences so far are positive compared to monolithic applications, we're conscious of the fact that not enough time has passed for us to make a full judgement.
然而,尽管有这些积极的经验,我们并不认为我们确信微服务是软件架构的未来方向。虽然与整体应用程序相比,我们迄今为止的经验是积极的,但我们意识到,我们还没有足够的时间来做出全面的判断。

Often the true consequences of your architectural decisions are only evident several years after you made them. We have seen projects where a good team, with a strong desire for modularity, has built a monolithic architecture that has decayed over the years. Many people believe that such decay is less likely with microservices, since the service boundaries are explicit and hard to patch around. Yet until we see enough systems with enough age, we can't truly assess how microservice architectures mature.
通常,架构决策的真正后果只有在做出决策几年后才会显现出来。我们见过一些项目,其中一个优秀的团队对模块化有着强烈的渴望,但他们构建的整体架构多年来已经衰落。许多人认为,微服务不太可能出现这种衰退,因为服务边界是明确的并且很难修补。然而,在我们看到足够多、有足够历史的系统之前,我们无法真正评估微服务架构的成熟程度。

There are certainly reasons why one might expect microservices to mature poorly. In any effort at componentization, success depends on how well the software fits into components. It's hard to figure out exactly where the component boundaries should lie. Evolutionary design recognizes the difficulties of getting boundaries right and thus the importance of it being easy to refactor them. But when your components are services with remote communications, then refactoring is much harder than with in-process libraries. Moving code is difficult across service boundaries, any interface changes need to be coordinated between participants, layers of backwards compatibility need to be added, and testing is made more complicated.
人们认为微服务成熟度不佳肯定是有原因的。在任何组件化努力中,成功取决于软件与组件的配合程度。很难准确地弄清楚组件边界应该位于哪里。进化设计认识到正确确定边界的困难,因此认识到易于重构边界的重要性。但是,当您的组件是具有远程通信的服务时,重构比进程内库要困难得多。跨服务边界移动代码很困难,任何接口更改都需要在参与者之间协调,需要添加向后兼容性层,并且测试变得更加复杂。

Our colleague Sam Newman spent most of 2014 working on a book that captures our experiences with building microservices. This should be your next step if you want a deeper dive into the topic.
我们的同事 Sam Newman 2014 年的大部分时间都在写一本书,该书记录了我们构建微服务的经验。如果您想更深入地了解该主题,这应该是您的下一步。

Another issue is If the components do not compose cleanly, then all you are doing is shifting complexity from inside a component to the connections between components. Not just does this just move complexity around, it moves it to a place that's less explicit and harder to control. It's easy to think things are better when you are looking at the inside of a small, simple component, while missing messy connections between services.
另一个问题是,如果组件不能干净地组合,那么您所做的就是将复杂性从组件内部转移到组件之间的连接。这不仅会改变复杂性,还会将其转移到一个不那么明确且更难以控制的地方。当您查看一个小而简单的组件的内部时,很容易认为事情变得更好了,同时忽略了服务之间混乱的连接。

Finally, there is the factor of team skill. New techniques tend to be adopted by more skillful teams. But a technique that is more effective for a more skillful team isn't necessarily going to work for less skillful teams. We've seen plenty of cases of less skillful teams building messy monolithic architectures, but it takes time to see what happens when this kind of mess occurs with microservices. A poor team will always create a poor system - it's very hard to tell if microservices reduce the mess in this case or make it worse.
最后,还有团队技能的因素。新技术往往会被更熟练的团队采用。但对于技术水平较高的团队来说更有效的技术不一定适用于技术水平较低的团队。我们已经看到很多技术水平较低的团队构建混乱的整体架构的案例,但是需要时间来看看当微服务发生这种混乱时会发生什么。一个糟糕的团队总是会创建一个糟糕的系统 - 很难判断微服务是否会减少这种情况下的混乱或使情况变得更糟。

One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. (Although this advice isn't ideal, since a good in-process interface is usually not a good service interface.)
我们听到的一个合理的论点是你不应该 从微服务架构开始。反而 从一个整体开始, 保持模块化,一旦出现就将其拆分为微服务 整体成为一个问题。 (虽然 这个建议并不理想,因为好的进程内接口通常不是好的服务接口。)

So we write this with cautious optimism. So far, we've seen enough about the microservice style to feel that it can be a worthwhile road to tread. We can't say for sure where we'll end up, but one of the challenges of software development is that you can only make decisions based on the imperfect information that you currently have to hand.
因此,我们怀着谨慎乐观的态度写下这篇文章。到目前为止,我们已经看到了 足够了解微服务风格,感觉它可以 一条值得走的路。我们不能确定我们最终会走向何方,但软件开发的挑战之一是您只能根据当前掌握的不完美信息做出决策。


Footnotes  脚注

1: The term “microservice” was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as “fine grained SOA” was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Daniel Terhorst-North, Evan Botcher and Graham Tackley.
1: 在软件研讨会上讨论了“微服务”一词 2011 年 5 月,威尼斯附近的建筑师们描述了 参与者认为这是一种共同的建筑风格 他们最近一直在探索。 2012 年 5 月,同一小组决定 “微服务”是最合适的名称。詹姆斯介绍了其中一些 2012 年 3 月在克拉科夫 33rd Degree 举办的案例研究 微服务 - Java,Unix Way大约在同一时间Fred George 也这么做了。 Netflix 的 Adrian Cockcroft 描述了这一点 “细粒度 SOA”方法开创了 Web 风格 规模与本文中提到的许多其他人一样 - Joe 沃尔恩斯、丹尼尔·特霍斯特-诺斯、埃文·博彻和 格雷厄姆·泰克利.

2: The term monolith has been in use by the Unix community for some time. It appears in The Art of Unix Programming to describe systems that get too big.
2: Unix 社区已经使用了“monolith”一词 时间。它出现在《Unix 编程艺术》中,用来描述变得太大的系统。

3: Many object-oriented designers, including ourselves, use the term service object in the Domain-Driven Design sense for an object that carries out a significant process that isn't tied to an entity. This is a different concept to how we're using “service” in this article. Sadly the term service has both meanings and we have to live with the polyseme.
3: 许多面向对象的设计者,包括我们自己,都使用 领域驱动设计意义上的术语服务对象是指执行重要操作的对象 不依赖于实体的流程。这是一个不同的 我们在本文中如何使用“服务”的概念。可悲的是 服务一词具有双重含义,我们必须接受 多义词。

4: We consider an application to be a social construction that binds together a code base, group of functionality, and body of funding.
4: 我们认为应用程序是一种社会结构,它将代码库、一组代码绑定在一起 功能和资金来源。

5: We can't resist mentioning Jim Webber's statement that ESB stands for “Erroneous Spaghetti Box”.
5: 我们无法抗拒提及 Jim Webber 的声明:ESB 代表“错误的意大利面条盒”

6: Netflix makes the link explicit - until recently referring to their architectural style as fine-grained SOA.
6: Netflix 明确提供了该链接 - 直到最近才提到 他们的架构风格是细粒度的 SOA。

7: At extremes of scale, organisations often move to binary protocols - protobufs for example. Systems using these still exhibit the characteristic of smart endpoints, dumb pipes - and trade off transparency for scale. Most web properties and certainly the vast majority of enterprises don't need to make this tradeoff - transparency can be a big win.
7: 在极端规模下,组织通常会转向二进制 协议 - 例如protobuf 。使用这些的系统仍然表现出智能端点、哑管道的特征 - 并权衡透明度 为了规模。大多数网络属性,当然是绝大多数 的企业不需要进行这种权衡 - 透明度 可以是一个巨大的胜利。

8: 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.
8: 我们声称单体是一个有点不诚实 单一语言 - 为了在当今的网络上构建系统,您 可能需要了解 JavaScript 和 XHTML、CSS、您的服务器 选择的辅助语言,SQL 和 ORM 方言。几乎单身 语言,但你知道我们的意思。

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.
9: “YAGNI”或“You Aren’t Going To Need It”是XP 原则,劝诫人们不要添加功能,除非您知道 你需要它们。

10: Adrian Cockcroft specifically mentions “developer self-service” and “Developers run what they wrote”(sic) in this excellent presentation delivered at Flowcon in November, 2013.
10: Adrian Cockcroft 特别提到“开发者自助服务” 以及 11 月份在 Flowcon 上发表的精彩演讲中的“开发人员运行他们编写的内容”(原文如此), 2013.

11: 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.
11: 我们在这里有点不诚实。明显部署 更多的服务,在更复杂的拓扑中比 部署单个整体。幸运的是,模式减少了这种情况 复杂性——但对工具的投资仍然是必须的。

12: In fact, Daniel Terhorst-North refers to this style as Replaceable Component Architecture rather than microservices. Since this seems to talk to a subset of the characteristics we prefer the latter.
12: 事实上,Daniel Terhorst-North 将这种风格称为可替换组件架构,而不是微服务。自从这 似乎与我们更喜欢的特征的子集有关 后者。

13: Kent Beck highlights this as one his design principles in Implementation Patterns.
13: 肯特贝克强调这是他的设计原则之一 实施模式

14: And SOA is hardly the root of this history. I remember people saying “we've been doing this for years” when the SOA term appeared at the beginning of the century. One argument was that this style sees its roots as the way COBOL programs communicated via data files in the earliest days of enterprise computing. In another direction, one could argue that microservices are the same thing as the Erlang programming model, but applied to an enterprise application context.
14: SOA 很难说是这段历史的根源。我记得人们说 当 SOA 术语出现在 本世纪初。一种说法是这种风格 将其根源视为 COBOL 程序通过数据进行通信的方式 企业计算早期的文件。在另一个 方向,人们可能会说微服务是同一件事 与 Erlang 编程模型一样,但应用于企业 应用程序上下文。

References  参考

While this is not an exhaustive list, there are a number of sources that practitioners have drawn inspiration from or which espouse a similar philosophy to that described in this article.
虽然这不是一个详尽的列表,但从业者可以从许多来源中汲取灵感,或者拥护与本文中描述的类似哲学。

Blogs and online articles
博客和在线文章

Books  图书

Presentations  演讲

Papers  文件

  • L. Lamport, “The Implementation of Reliable Distributed Multiprocess Systems”, 1978 http:// research.microsoft.com/en-us/um/people/lamport/pubs/implementation.pdf
    L. Lamport,“可靠的分布式多进程系统的实现”,1978 年 http://research.microsoft.com/en-us/um/people/lamport/pubs/implementation.pdf
  • L. Lamport, R. Shostak, M. Pease, “The Byzantine Generals Problem”, 1982 (available at) http:// www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.pdf
    L. Lamport、R. Shostak、M. Pease,“拜占庭将军问题”,1982 年(可在以下位置获取)http://www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.pdf
  • R.T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, 2000 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
    RT Fielding,“基于网络的软件架构的架构风格和设计”,2000 年 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
  • E. A. Brewer, “Towards Robust Distributed Systems”, 2000 http://www.cs.berkeley.edu/ ~brewer/cs262b-2004/PODC-keynote.pdf
    EA Brewer,“迈向稳健的分布式系统”,2000 年 http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
  • E. Brewer, “CAP Twelve Years Later: How the 'Rules' Have Changed”, 2012, http:// www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
    E. Brewer,“CAP 十二年后:‘规则’如何变化”,2012 年,http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

Further Reading  进一步阅读

The above list captures the references we used when we originally wrote this article in early 2014. For an up to date list of sources for more information, take a look at the Microservice Resource Guide.
上面的列表列出了我们在 2014 年初最初撰写本文时使用的参考资料。有关详细信息的最新来源列表,请查看微服务资源指南

Significant Revisions  重大修改

25 March 2014: last installment on are microservices the future?

24 March 2014: added section on evolutionary design

19 March 2014: added sections on infrastructure automation and design for failure

18 March 2014: added section on decentralized data

17 March 2014: added section on decentralized governance

14 March 2014: added section on smart endpoint and dumb pipes

13 March 2014: added section on products not projects

12 March 2014: added section on organizing around business capabilities

10 March 2014: published first installment