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 25 三月 2014
Contents 内容
- Characteristics of a Microservice Architecture
微服务架构的特征- Componentization via Services
通过服务实现组件化 - Organized around Business Capabilities
围绕业务能力进行组织 - Products not Projects 产品而非项目
- Smart endpoints and dumb pipes
智能端点和哑管道 - Decentralized Governance
去中心化治理 - Decentralized Data Management
分散式数据管理 - Infrastructure Automation
基础设施自动化 - Design for failure 为失败而设计
- Evolutionary Design 进化设计
- Componentization via Services
- Are Microservices the Future?
微服务是未来吗?
Sidebars 侧边栏
- How big is a microservice?
微服务有多大? - Microservices and SOA 微服务和 SOA
- Many languages, many options
多种语言,多种选择 - Battle-tested standards and enforced standards
久经考验的标准和强制执行的标准 - Make it easy to do the right thing
让做正确的事变得容易 - The circuit breaker and production ready code
断路器和生产就绪代码 - Synchronous calls considered harmful
被视为有害的同步调用
"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)进行通信。这些服务围绕业务功能构建,可由全自动部署机制独立部署。这些服务只有最低限度的集中管理,这些服务可能用不同的编程语言编写,并使用不同的数据存储技术。
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 executable[2]. Any changes to the
system involve building and deploying a new version of the
server-side application.
要开始解释微服务风格,将其与单体式风格进行比较是很有用的:单体式应用程序是作为单个单元构建的。企业应用程序通常由三个主要部分构建:客户端用户界面(由在用户计算机上的浏览器中运行的 HTML 页面和 javascript 组成)、数据库(由插入到通用的(通常是关系型)数据库管理系统中的许多表组成)和服务器端应用程序。服务器端应用程序将处理 HTTP 请求、执行域逻辑、从数据库中检索和更新数据,以及选择和填充要发送到浏览器的 HTML 视图。这个服务器端应用程序是一个整体 - 一个单一的逻辑可执行文件 [2]。对系统的任何更改都涉及构建和部署服务器端应用程序的新版本。
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.
单体应用程序可以成功,但越来越多的人对它们感到沮丧 - 特别是随着越来越多的应用程序被部署到云中。更改周期是联系在一起的 - 对应用程序的一小部分进行的更改需要重新构建和部署整个整体。随着时间的流逝,通常很难保持良好的模块化结构,这使得保留应该只影响该模块中的一个模块的更改变得更加困难。扩展需要扩展整个应用程序,而不是需要更多资源的部分。
![](microservices/images/sketch.png)
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] 中的服务对象概念不同。
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] 在单个进程中由多个库组成,则对任何单个组件的更改都会导致必须重新部署整个应用程序。但是,如果将该应用程序分解为多个服务,则可以预期许多单个服务更改只需要重新部署该服务。这不是绝对的,一些变化会改变服务接口,导致一些协调,但一个好的微服务架构的目标是通过服务契约中的内聚服务边界和演进机制来最小化这些变化。
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年
![](microservices/images/conways-law.png)
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.
微服务的划分方法则不同,它拆分为围绕业务能力组织的服务。此类服务采用该业务领域的软件的广泛堆栈实现,包括用户界面、持久存储和任何外部协作。因此,这些团队是跨职能的,包括开发所需的全方位技能:用户体验、数据库和项目管理。
![](microservices/images/PreferFunctionalStaffOrganization.png)
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
messaging[7]. The best expression of
the first is
最常用的两种协议是带有资源API的HTTP请求-响应和轻量级消息传递[7]。第一个最好的表达是
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'[8] 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”[8]困境。这些技术和围绕它们成长的工具通过减少服务之间的时间耦合来限制对中央合同管理的需求。
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
ethos[10]. 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 点被寻呼机吵醒,这无疑是在编写代码时关注质量的强大动力。这些想法与传统的集中式治理模式相去甚远。
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.
此问题在应用程序之间很常见,但也可能在应用程序中发生,特别是当该应用程序被划分为单独的组件时。思考这个问题的一个有用方法是 Bounded Context 的 Domain-Driven Design 概念。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.
除了分散有关概念模型的决策外,微服务还分散了数据存储决策。虽然整体式应用程序更喜欢使用单个逻辑数据库来存储持久性数据,但企业通常更喜欢跨一系列应用程序使用单个数据库 - 其中许多决策都是由供应商围绕许可的商业模式驱动的。微服务更愿意让每个服务管理自己的数据库,可以是同一数据库技术的不同实例,也可以是完全不同的数据库系统,这种方法称为多语言持久性。可以在单体架构中使用多语言持久性,但它在微服务中出现得更频繁。
![](microservices/images/decentralised-data.png)
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.
许多使用微服务构建的产品或系统都是由具有丰富持续交付经验的团队构建的,其前身是持续集成。以这种方式构建软件的团队广泛使用基础架构自动化技术。如下所示的生成管道对此进行了说明。
![](microservices/images/basic-pipeline.png)
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
matter[11].
一个整体式应用程序将非常愉快地在这些环境中构建、测试和推送。事实证明,一旦您投资了单体的生产路径自动化,那么部署更多应用程序似乎就不再那么可怕了。请记住,CD 的目标之一是让部署变得无聊,所以无论是一个还是三个应用程序,只要它仍然无聊就没关系 [11]。
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.
我们看到团队使用广泛的基础设施自动化的另一个领域是在生产环境中管理微服务时。与我们上面的断言相反,只要部署是无聊的,单体和微服务之间就没有太大区别,两者的运营环境可能会截然不同。
![](microservices/images/micro-deployment.png)
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 的 Simian Army 在工作日内诱发服务甚至数据中心的故障,以测试应用程序的弹性和监控能力。
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
upgradeability[12] - 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],这意味着我们寻找可以想象在不影响其协作者的情况下重写组件的点。事实上,许多微服务组织更进一步,明确地期望许多服务被废弃,而不是长期发展。
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]。您希望将同时更改的内容保留在同一个模块中。系统中很少更改的部分应该与当前正在经历大量流失的系统处于不同的服务中。如果您发现自己反复将两个服务更改在一起,则表明它们应该合并。
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])
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.
当然,人们可能会认为微服务成熟度不佳是有原因的。在任何组件化的努力中,成功与否都取决于软件与组件的契合程度。很难确切地弄清楚组件边界应该在哪里。渐进式设计认识到正确划分边界的困难,因此也认识到重构边界的重要性。但是,当您的组件是具有远程通信的服务时,重构比使用进程内库要困难得多。跨服务边界移动代码很困难,任何接口更改都需要在参与者之间进行协调,需要添加向后兼容层,并且测试变得更加复杂。
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 月,James 在克拉科夫的 33rd Degree 上以 Microservices - Java, the Unix Way 的形式介绍了其中一些想法,Fred George 也差不多在同一时间做了研究。Netflix 的 Adrian Cockcroft 将这种方法描述为“细粒度 SOA”,他开创了网络规模的风格,本文中提到的许多其他人——Joe Walnes、Daniel Terhorst-North、Evan Botcher 和 Graham Tackley。
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社区已经使用了一段时间的单体。它出现在 The Art of Unix Programming 中,用来描述变得太大的系统。
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:在极端规模下,组织经常转向二进制协议 - 例如protobufs。使用这些系统的系统仍然表现出智能端点、哑管道的特征,并在透明度与规模之间做出权衡。大多数 Web 资产,当然还有绝大多数企业都不需要做出这种权衡——透明度可能是一个巨大的胜利。
8:
"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.
8:“YAGNI”或“你不需要它”是XP的原则,并劝诫在你知道你需要它们之前不要添加功能。
9:
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.
9:声称单体是单一语言有点不合时宜——为了在当今的 Web 上构建系统,您可能需要了解 JavaScript 和 XHTML、CSS、您选择的服务器端语言、SQL 和 ORM 方言。几乎不是单一的语言,但你知道我们的意思。
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在2013年11月的Flowcon大会上特别提到了“开发人员自助服务”和“开发人员运行他们所写的内容”(原文如此)。
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:Kent Beck在《实现模式》中强调了这一点,这是他的设计原则之一。
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
博客和在线文章
- Clemens Vasters’ blog
on cloud at microsoft
Clemens Vasters 关于微软云的博客 - David
Morgantini’s introduction to the topic on his blog
大卫·摩根蒂尼(David Morgantini)在他的博客上对该主题的介绍 - 12 factor apps from Heroku
来自 Heroku 的 12 个因素应用程序 - UK Government
Digital Service design principles
英国政府数字服务设计原则 - Jimmy Nilsson’s blogand article
on infoq about Cloud Chunk Computing
Jimmy Nilsson 在 infoq 上发表的关于云块计算的博客和文章 - Alistair
Cockburn on Hexagonal architectures
阿利斯泰尔·科伯恩(Alistair Cockburn)谈六边形架构
Books 书
- Release it 释放它
- Rest in practice 在实践中休息
- Web
API Design (free ebook). Brian Mulloy, Apigee.
Web API 设计(免费电子书)。布莱恩·穆洛伊(Brian Mulloy),阿皮吉(Apigee)。 - Enterprise Integration
Patterns
企业集成模式 - Art of unix programming
Unix编程的艺术 - Growing Object Oriented Software, Guided
by Tests
以测试为指导的面向对象软件的发展 - The Modern Firm: Organizational Design for
Performance and Growth
现代公司:绩效和增长的组织设计 - Continuous Delivery: Reliable Software
Releases through Build, Test, and Deployment Automation
持续交付:通过构建、测试和部署自动化实现可靠的软件发布 - Domain-Driven Design: Tackling Complexity
in the Heart of Software
领域驱动设计:解决软件核心的复杂性
Presentations 介绍
- Architecture
without Architects. Erik Doernenburg.
没有建筑师的建筑。埃里克·多嫩堡。 - Does
my bus look big in this?. Jim Webber and Martin Fowler, QCon
2008
我的公共汽车看起来很大吗?吉姆·韦伯(Jim Webber)和马丁·福勒(Martin Fowler),QCon 2008 - Guerilla
SOA. Jim Webber, 2006
游击SOA。吉姆·韦伯,2006 - Patterns of Effective
Delivery. Daniel Terhorst-North, 2011.
有效交付的模式。丹尼尔·特霍斯特-诺斯,2011 年。 - Adrian Cockcroft's
slideshare channel.
阿德里安·科克罗夫特(Adrian Cockcroft)的幻灯片共享频道。 - Hydras and Hypermedia. Ian
Robinson, JavaZone 2010
九头蛇和超媒体。Ian Robinson,JavaZone 2010 - Justice will take a million intricate
moves. Leonard Richardson, Qcon 2008.
正义将采取一百万个错综复杂的举动。伦纳德·理查森(Leonard Richardson),Qcon 2008。 - Java, the UNIX way. James
Lewis, JavaZone 2012
Java,UNIX 的方式。James Lewis,JavaZone 2012 年 - Micro
services architecture. Fred George, YOW! 2012
微服务架构。弗雷德·乔治,哎呀!2012 - Democratising attention data
at guardian.co.uk. Graham Tackley, GOTO Aarhus 2013
guardian.co.uk 的注意力数据民主化。Graham Tackley, GOTO 奥胡斯 2013 - Functional Reactive
Programming with RxJava. Ben Christensen, GOTO Aarhus 2013
(registration required).
使用 RxJava 进行函数式响应式编程。Ben Christensen,GOTO Aarhus 2013(需要注册)。 - Breaking
the Monolith. Stefan Tilkov, May 2012.
打破巨石。Stefan Tilkov,2012 年 5 月。
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 (available at) 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
R.T. Fielding,“Architectural Styles and the Design of Network-based Software Architectures”,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
E. A. 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