【译】微服务(microservices)

【译】微服务(microservices)

原文链接:https://martinfowler.com/articles/microservices.html

目录

  • 微服务体系结构的特征
  • 通过服务拆分实现组件化
  • 围绕业务功能进行组织
  • 产品不是项目
  • 智能端点和轻量级通信
  • 分散治理
  • 分散的数据管理
  • 基础设施自动化
  • 容错设计
  • 演进式设计
  • 微服务是未来的趋势吗?
  • 微服务有多大?
  • Microservices和SOA
  • 多种语言,多种选择
  • 经过实战检验的标准和强制执行的标准
  • 让做正确的事情变得容易
  • 断路器和可随时上线的代码
  • 同步调用的弊端

术语

术语原词 释义
Microservice Architecture 微服务架构
automated deployment 自动部署
centralized management 集中管理
communicating 通信、交互
lightweight mechanisms 轻量级机制
monolithic application 单体应用/集中式应用
load-balancer 负载均衡器
modular structure 模块化结构
Componentization/components 组件化/组件
physical world 客观世界
OO programs 面向对象编程
encapsulation 封装
processes 进程
cross-team 跨团队
boundaries 边界
business capability 业务能力
business area 业务领域
cross-functional 跨职能的
message bus. 消息总线
Smart endpoints 智能端点
dumb pipes 轻量级通信
Decentralized Governance 去中心化治理
Infrastructure Automation 基础设施自动化
Design for failure 容错机制设计
Evolutionary Design 演进/迭代 设计
coarser-grained 粗粒度的

一个新架构术语的定义

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.

虽然没有对这种架构风格的精确定义,但围绕业务功能的组织,自动部署,端点智能以及在编程语言和数据方面进行去中心化的控制方面存在某些共同特征。

“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.

简单来说,微服务架构风格[1]就是以开发一组小型服务的方式来开发一个独立的应用系统的,每个单体服务都在自己独立的进程中运行,并以HTTP资源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.

这些服务具有最低限度的集中管理,可以用不同的编程语言编写,也可以使用不同的数据存储技术。

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.

企业级应用通常由三个主要部分构成:

  • 客户端用户界面(由在用户机器上的浏览器中运行的HTML页面和javascript组成)
  • 数据库(由插入到公共(通常是关系)数据库管理系统中的许多表组成)
  • 服务器端应用程序。

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.

服务器端应用负责处理HTTP请求、执行域逻辑、从数据库检索和更新数据,并选择和填充要发送到浏览器的HTML视图。

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.

这个服务器端应用是一个整体 - 一个可执行的逻辑程序[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.

随着时间的推移,单体应用也很难保持一个良好的模块化结构,因为把一个模块的变更影响控制在该模块内将会变得非常困难。当对系统进行扩展时,不得不扩展整个应用系统,而不是对需要更多资源的部分应用程序进行扩展。

单应用架构和微服务架构

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服务请求或远程过程调用之类的机制进行通信。(这与许多面向对象程序中的服务对象的概念不同[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.

如果您在单个进程中有一个由多个库组成的应用程序4,则对任何单个组件的更改都会导致必须重新部署整个应用程序。

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.

但是这也不是绝对的,比如一些更改将会更改服务接口,从而导致一些协调问题,但是一个好的微服务体系结构的目标是通过服务契约中的内聚服务边界和演进机制将这些更改最小化。

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.

但是这种方式也有不足的地方。主要是远程调用比进程内调用更昂贵,因此远程api需要是粗粒度的,但这会比较难用。

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.

如果您需要更改组件之间的职责分配,那么当你需要跨进程时,这种行为的迁移将更加困难。

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.

当希望将大型应用程序分解为多个模块时,管理通常关注于技术层,重要的包括UI团队、服务器端逻辑团队和数据库团队。

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[5] in action.

一个优秀的团队将围绕这一点进行改善,并选择两害相权取其轻——只需将逻辑强制应用到他们能够访问的任何应用程序中。换句话说,逻辑无处不在。这是康威定律5的一个例子。

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

康韦定律的作用

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.

因此,团队是跨职能的,包括开发所需的全方位技能:用户体验、数据库和项目管理。

由团队边界加强的服务边界

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.

一个常见的灵感是Amazon的“你构建,你运行它”的概念,在这个概念中,开发团队需要对产品承担全部责任。这使得开发人员能够在日常中关注到软件运行情况,并增加与用户的联系,同时必须承担一些支持工作。

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.

使用微服务构建的应用程序旨在尽可能地解耦和内聚 - 采用独立的业务逻辑,表现的更像经典Unix意义上的过滤器一样,接受请求、处理业务逻辑,然后返回响应。

These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.

它们更喜欢简单的REST风格,而不是使用复杂的协议,如WS-Choreography、BPEL或集中式框架。

The two protocols used most commonly are HTTP request-response with resource API’s and lightweight messaging[8].

最常用的两种协议是带有资源API的HTTP请求-响应协议和轻量级消息传递[8]协议。 第一个是最好的描述是:善于利用网络,而不是限制。

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’9dilemma 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 困境的优雅方法。这些技术和工具在契约周边生长出来,由于减少了服务之间在时域(temporal)上的耦合,从而抑制了对中心契约管理的需求。

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 ethos11. 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.

也许分散治理治理技术的极盛时期,就是亚马逊的“你构建,你运行”的理念开始普及的时候。 每个团队负责他们构建的软件的全生命周期,包括持续的软件的运维。 把运维的这种能力放到团队的做法目前还不是主流的,但我们确实看到越来越多的公司将运维的职责推向开发团队。 Netflix是另一个采用这种模式的组织11。 如果你不想每天凌晨3点被喊起来去改bug,那么你就该在编写代码时投入更多的精力和时间。 但是这些想法与传统的集中治理模式相差甚远。

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.

上述问题在不同的应用程序之间经常出现,当然应用程序内部也会出现,尤其是当一个应用程序被分成不同组件的情况下。思考这类问题的一个可靠的方法,就是使用领域驱动设计(Domain-Driven Design, DDD)中的“限界上下文”的概念。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.

除了关于概念模型的分散决策之外,微服务还分散了数据存储决策。 虽然单体应用程序通常都是使用单个逻辑数据库来存储持久性数据,但企业往往喜欢一系列单体应用共用一个单独的数据库 - 其中许多决策是通过供应商围绕许可的商业模型来实现的(供应商的版权商业模式所驱动)。 微服务体系中更偏向让每个服务实例管理自己的数据库,可以是相同数据库技术的不同实例,也可以是完全不同的数据库系统 – 这种方法称为 Polyglot Persistence(多语言持久化)。在一个单体系统中也能使用多语种持久化,但它在微服务中更常出现。

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.

许多使用微服务构建的产品或系统都是由具有大量 持续交付与其前身持续集成 经验的团队构建的。以这种方式构建软件的团队广泛使用了基础设施自动化技术。如下图的构建流水线所示:

基本构建流程

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.

由于这不是一篇关于持续交付的文章,我们将在这里只关注几个关键特性。我们希望我们的软件能够正常工作,所以我们运行了大量的自动化测试。让可工作的软件达到“晋级”(Promotion)状态从而“推上”流水线,就意味着可以在 每一个新的环境中,对软件进行 自动化部署 。

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 matter12.

对于单体应用来说,可以轻松的在上述的各个环境中进行构建、测试和发布。其结果是,一旦投入到自动化平台, 那么部署更多的应用系统似乎就不再可怕。记住,持续交付的目的之一,是让“部署”工作变得“无聊”。所以不管是一个还是三个应用系统,只要是部署工作,就依旧很“无聊”,那么就没什么可担心的了 12

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.

另一个方面,我们发现使用微服务的团队更加依赖于基础设施的自动化。与前面我们对比单体系统和微服务所说的正相反,只要部署工作很无聊,那么在这一点上单块系统和微服务就没什么区别。然而,两者在运维领域的情况却截然不同。

模块部署通常是不同的

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 upgradeability13 - 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.

每当试图要将软件系统分解为各个组件时,就会面临这样的问题,即如何进行切分——我们决定切分应用系统时应该遵循的原则是什么?首要的因素,组件可以被独立替换和更新的 13 ——这意味着,需要寻找这些点,即想象着能否在其中一个点上重写该组件,而无须影响该组件的其他合作组件。事实上,许多微服务团队考虑的更多的是,如何明确地预期许多服务将来会报废,而不是守着这些服务做长期迭代。

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 14. 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.

这种强调可更换性的特点,是模块化设计一般性原则的一个特例,需求变更通过进行模块化的方式实现。大家都愿意将那些能在同时发生变化的东西,放到同一个模块中。系统中那些很少发生变化的部分,应该被放到不同的服务中,以区别于那些当前正在经历大量变动(churn)的部分。如果发现需要同时反复变更两个服务时,这就是它们两个需要被合并的一个信号。

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. 15)

我们所了解到的实践先驱包括:亚马逊、Netflix、The Guardian、The UK Government Digital Service、realestate.com.au、Forward和comparethemarket.com。在2013年的技术大会圈子里充满了各种各样的正在转向微服务的公司案例——包括Travis CI。另外还有大量的组织,它们长期以来一直在做着我们可以归类为微服务的产品,却从未使用过这个名字(这通常被标记为SOA—— 尽管正如我们所说,SOA会表现出各种自相矛盾的形式 15 )。

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.

因此,我们持谨慎乐观的态度来撰写此文。到目前为止,我们已经看到足够多的有关微服务风格的项目,并且觉得这是一条值得去探索的道路。我们不能肯定地说,道路的尽头在哪里。但是,软件开发的挑战之一,就是只能基于 “目前手上拥有但还不够完善” 的信息来做出决策。

TIPS

Tips1 : How big is a microservice?-一个微服务应该有多大?

Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon’s notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we’ve seen setups where a team of half-a-dozen would support half-a-dozen services.

尽管“微服务”已经成为一个流行的名字,但是这个名字确实会不幸地导致大家对服务规模的关注,并且产生了有关什么是“微”的争论。在与微服务从业者的交谈中,我们看到了有关服务的一系列规模。所听到的最大的一个服务的规模,是遵循了亚马逊的“两个比萨团队”(即一个团队可以被两个比萨所喂饱)的理念,这意味着这个团队不会多于12人。对于规模较小的服务,我们已经看到一个6人的团队在支持6个服务。

This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn’t be lumped under one microservices label. At the moment we think it’s better to group them together, but it’s certainly possible that we’ll change our mind as we explore this style further.

这引出了一个问题,即“每12人做一个服务”和“每人做一个服务”这样有关服务规模的差距,是否已经大到不能将两者都纳入微服务之下?此时,我们认为最好还是把它们归为一类,但是随着进一步探索这种架构风格,绝对有可能我们会在将来改变主意。

Tips2 : Microservices and SOA-微服务与SOA

When we’ve talked about microservices a common question is whether this is just Service Oriented Architecture (SOA) that we saw a decade ago. There is merit to this point, because the microservice style is very similar to what some advocates of SOA have been in favor of. The problem, however, is that SOA means too many different things, and that most of the time that we come across something called “SOA” it’s significantly different to the style we’re describing here, usually due to a focus on ESBs used to integrate monolithic applications.

当我们谈起微服务时,一个常见的问题就会出现:是否微服务仅仅是十多年前所看到的“面向服务的架构”(Service Oriented Architecture, SOA)?这样问是有道理的,因为微服务风格非常类似于一些支持SOA的人所赞成的观点。然而,问题在于SOA这个词儿意味着太多不同的东西。而且大多数时候,我们所遇到的某些被称作”SOA”的事物,明显不同于本文所描述的风格。这通常由于它们专注于ESB,来集成各个单体应用。

In particular we have seen so many botched implementations of service orientation - from the tendency to hide complexity away in ESB’s 6, to failed multi-year initiatives that cost millions and deliver no value, to centralised governance models that actively inhibit change, that it is sometimes difficult to see past these problems.

特别地,我们已经看到如此之多的面向服务的拙劣实现——从将系统复杂性隐藏于ESB中的趋势 6 ,到花费数百万进行多年却没有交付任何价值的失败项目,到顽固抑制变化发生的中心化技术治理模型——以至于有时觉得其所造成的种种问题真的不堪回首。

Certainly, many of the techniques in use in the microservice community have grown from the experiences of developers integrating services in large organisations. The Tolerant Reader pattern is an example of this. Efforts to use the web have contributed, using simple protocols is another approach derived from these experiences - a reaction away from central standards that have reached a complexity that is, frankly, breathtaking. (Any time you need an ontology to manage your ontologies you know you are in deep trouble.)

当然,在微服务社区投入使用的许多技术,源自各个开发人员将各种服务集成到各个大型组织的经验。“容错读取”(Tolerant Reader)模式就是这样一个例子。对于Web的广泛使用,使得人们不再使用一些中心化的标准,而使用一些简单的协议。坦率地说,这些中心化的标准,其复杂性已经达到令人吃惊的程度。(任何时候,如果需要一个本体(ontology)来管理其他各个本体,那么麻烦就大了)

This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA 7, perhaps service orientation done right. Either way, the fact that SOA means such different things means it’s valuable to have a term that more crisply defines this architectural style.

这种常见的SOA的表现,已使得一些微服务的倡导者完全拒绝将自己贴上SOA的标签。尽管其他人会将微服务看作是SOA的 一种形式 7 ,也许微服务就是以正确的形式来实现面向服务的SOA 。不管是哪种情况,SOA意味着很多的不同事物,这表明用一个更加干净利落的术语来命名这种架构风格是很有价值的。

Tips3 : Many languages, many options-多种编程语言,多种选择可能

The growth of JVM as a platform is just the latest example of mixing languages within a common platform. It’s been common practice to shell-out to a higher level language to take advantage of higher level abstractions for decades. As is dropping down to the metal and writing performance sensitive code in a lower level one. However, many monoliths don’t need this level of performance optimisation nor are DSL’s and higher level abstractions that common (to our dismay). Instead monoliths are usually single language and the tendency is to limit the number of technologies in use [10].

做为一个平台,JVM的发展仅仅是一个将各种编程语言混合到一个通用平台的最新例证。近十年以来,在平台外层实现更高层次的编程语言,来利用更高层次的抽象,已经成为一个普遍做法。同样,在平台底层以更低层次的编程语言编写性能敏感的代码也很普遍。然而,许多单体系统并不需要这种级别的性能优化,另外DSL和更高层次的抽象也不常用(这令我们感到失望)。相反,许多单体应用通常就使用单一编程语言,并且有对所使用的技术数量进行 限制 的趋势 [10] 。

Tips4 : Battle-tested standards and enforced standards-”实战检验”的标准与“强制执行”的标准

It’s a bit of a dichotomy that microservice teams tend to eschew the kind of rigid enforced standards laid down by enterprise architecture groups but will happily use and even evangelise the use of open standards such as HTTP, ATOM and other microformats.

微服务的某些做法有点泾渭分明的味道,即他们趋向于避开被那些企业架构组织所制定的硬性实施的标准,而愉快地使用甚至传播一些开放标准,比如 HTTP、ATOM和其他微格式的协议。

The key difference is how the standards are developed and how they are enforced. Standards managed by groups such as the IETF only become standards when there are several live implementations of them in the wider world and which often grow from successful open-source projects.

这里的关键区别是,这些标准是如何被制定以及如何被实施的。像诸如IETF这样的组织所管理的各种标准,只有达到某些条件才能称为标准,即该标准在全球更广阔的地区有一些正在运行的实现案例,而且这些标准经常源自一些成功的开源项目。

These standards are a world apart from many in a corporate world, which are often developed by groups that have little recent programming experience or overly influenced by vendors.

这些标准组成了一个世界,它区别于来自企业世界的许多标准。企业世界中的标准,经常由这样特点的组织来开发,即缺乏用较新技术进行编程的经验,或受到供应商的过度影响。

Tips5 : Make it easy to do the right thing-让做正确的事情变得容易

One side effect we have found of increased automation as a consequence of continuous delivery and deployment is the creation of useful tools to help developers and operations folk. Tooling for creating artefacts, managing codebases, standing up simple services or for adding standard monitoring and logging are pretty common now. The best example on the web is probably Netflix’s set of open source tools, but there are others including Dropwizard which we have used extensively.

那些因实现持续交付和持续集成所增加的自动化工作的副产品,是创建一些对开发和运维人员有用的工具。现在,能完成下面工作的工具已经相当常见了:即创建工件(artefacts)、管理代码库、启动一些简单的服务、或增加标准的监控和日志功能。Web上最好的例子可能是Netflix提供的一套开源工具集,但也有其他一些好工具,包括我们已经广泛使用的Dropwizard。

Tips6 : The circuit breaker and production ready code-“断路器”与“可随时上线的代码”

Circuit Breaker appears in Release It!
alongside other patterns such as Bulkhead and Timeout. Implemented together, these patterns are crucially important when building communicating applications. This Netflix blog entry does a great job of explaining their application of them.

“断路器”(Circuit Breaker )一词与其他一些模式一起出现在《发布!》(Release It! )一书中,例如隔板(Bulkhead)和超时(Timeout)。当构建彼此通信的应用系统时,将这些模式加以综合运用就变得至关重要。Netflix公司的这篇很精彩的博客解释了这些模式是如何应用的。

Tips7 : Synchronous calls considered harmful-同步调用的弊端

Any time you have a number of synchronous calls between services you will encounter the multiplicative effect of downtime. Simply, this is when the downtime of your system becomes the product of the downtimes of the individual components. You face a choice, making your calls asynchronous or managing the downtime. At www.guardian.co.uk they have implemented a simple rule on the new platform - one synchronous call per user request while at Netflix, their platform API redesign has built asynchronicity into the API fabric.

一旦在一些服务之间进行多个同步调用,就会遇到宕机的乘法效应。简而言之,这意味着整个系统的宕机时间,是每一个单独模块各自宕机时间的乘积。此时面临着一个选择:是让模块之间的调用异步,还是去管理宕机时间?在www.guardian.co.uk网站,他们在新平台上实现了一个简单的规则——每一个用户请求都对应一个同步调用。然而在Netflix公司,他们重新设计的平台API将异步性构建到API的机制(fabric)中。

参考

作者

卫恒

发布于

2020-04-12

更新于

2022-04-23

许可协议

评论