加载中

This is a guest post by Chris Richardson. Chris is the founder of the original CloudFoundry.com, an early Java PaaS (Platform-as-a-Service) for Amazon EC2. He now consults with organizations to improve how they develop and deploy applications. He also blogs regularly about microservices at http://microservices.io.

==============

Microservices are currently getting a lot of attention: articles, blogs, discussions on social media, and conference presentations. They are rapidly heading towards the peak of inflated expectations on the Gartner Hype cycle. At the same time, there are skeptics in the software community who dismiss microservices as nothing new. Naysayers claim that the idea is just a rebranding of SOA. However, despite both the hype and the skepticism, the Microservice architecture pattern has significant benefits – especially when it comes to enabling the agile development and delivery of complex enterprise applications.

This blog post is the first in a 7-part series about designing, building, and deploying microservices. You will learn about the approach and how it compares to the more traditional Monolithic architecture pattern. This series will describe the various elements of the Microservice architecture. You will learn about the benefits and drawbacks of the Microservice architecture pattern, whether it makes sense for your project, and how to apply it.

Let’s first look at why you should consider using microservices.

这是一篇由 Chris Richardson 撰写的客座文章。Chris 是 CloudFoundry.com 的创始人,这是一个早期的用于 Amazon EC2 的 Java PaaS (Platform-as-a-Service平台即服务)。他现在为大型组织提供咨询服务,帮助他们提升开发和部署应用的能力。他还在有规律地写关于微服务的博客,博客地址:http://microservices.io

==============

目前,微服务得到较多的关注:论文,博文,社交媒体上的讨论,还有会议报告。他们处于期望膨胀期的顶峰,快速地向着登上 Gartner 趋势报告前进。同时,在软件社区还有一群怀疑论者,他们无视微服务,认为它没什么新意。反对派们声称,这种想法就是 SOA 的马甲。但是,不管是大肆宣传还是怀疑主义,微服务架构模式具有明显的好处——尤其谈到敏捷开发和复杂企业应用交付的时候。

这篇博文是一个关于设计、构建和部署微服务的七部系列的第一部分。你将会了解到微服务的方法和它与传统的单一架构模式的对比。这个系列将会详细说明微服务架构的众多元素。你将会了解到微服务架构模式的好处和缺点,对你的项目是否有意义,和怎样应用它。

现在,我们先看看为什么你应该考虑使用微服务。

Building Monolithic Applications

Let’s imagine that you were starting to build a brand new taxi-hailing application intended to compete with Uber and Hailo. After some preliminary meetings and requirements gathering, you would create a new project either manually or by using a generator that comes with Rails, Spring Boot, Play, or Maven. This new application would have a modular hexagonal architecture, like in the following diagram:

Graph-01

At the core of the application is the business logic, which is implemented by modules that define services, domain objects, and events. Surrounding the core are adapters that interface with the external world. Examples of adapters include database access components, messaging components that produce and consume messages, and web components that either expose APIs or implement a UI.

构建整体应用

假设你想要构建一个全新的打车应用与 Uber 和 Hailo 竞争。经过了一些预备会议和需求收集之后,你将会手工创建一个新的工程,或者使用 Rails、Spring Boot、Play 或 Maven 这类工具生成一个。这个新应用将会有一个模块化的六角形架构,就像下图这样:

Graph-01该应用的核心是服务模块、域对象模块和事件模块实现的业务逻辑。围绕在核心周围的是与外界交互的适配器。这些适配器包括数据库访问组件、生产和消费消息的消息传递组件、暴露 API 或实现 UI 的 web 组件。

Despite having a logically modular architecture, the application is packaged and deployed as a monolith. The actual format depends on the application’s language and framework. For example, many Java applications are packaged as WAR files and deployed on application servers such as Tomcat or Jetty. Other Java applications are packaged as self-contained executable JARs. Similarly, Rails and Node.js applications are packaged as a directory hierarchy.

Applications written in this style are extremely common. They are simple to develop since our IDEs and other tools are focused on building a single application. These kinds of applications are also simple to test. You can implement end-to-end testing by simply launching the application and testing the UI with Selenium. Monolithic applications are also simple to deploy. You just have to copy the packaged application to a server. You can also scale the application by running multiple copies behind a load balancer. In the early stages of the project it works well.

尽管具有合乎逻辑的模块化架构,但是该应用做为整体打包部署。具体的样式依赖应用的语言和框架。例如许多Java应用打成WAR包,部署在Tomcat或Jetty这样的应用服务器。还有一些Java应用打成独立可执行的JAR包。类似的,Rails和Node.js应用以目录层次的形式打包。

写成这种形式的应用极其普遍。它们非常易于开发,因为我们的IDE和其他工具专注于构建一个单独的应用。这样的应用通常也易于测试。通过简单地运行应用就可以实现端到端的测试,使用Selenium就可以测试UI。整体应用也易于部署。你仅仅需要复制打包的应用到服务器。你也可以通过在负载均衡器后面运行多个副本的方式扩展应用。在项目的早期阶段,这种方式运作的很好。

Marching Towards Monolithic Hell

Unfortunately, this simple approach has a huge limitation. Successful applications have a habit of growing over time and eventually becoming huge. During each sprint, your development team implements a few more stories, which, of course, means adding many lines of code. After a few years, your small, simple application will have grown into a monstrous monolith. To give an extreme example, I recently spoke to a developer who was writing a tool to analyze the dependencies between the thousands of JARs in their multi-million line of code (LOC) application. I’m sure it took the concerted effort of a large number of developers over many years to create such a beast.

Once your application has become a large, complex monolith, your development organization is probably in a world of pain. Any attempts at agile development and delivery will flounder. One major problem is that the application is overwhelmingly complex. It’s simply too large for any single developer to fully understand. As a result, fixing bugs and implementing new features correctly becomes difficult and time consuming. What’s more, this tends to be a downwards spiral. If the codebase is difficult to understand, then changes won’t be made correctly. You will end up with a monstrous, incomprehensible big ball of mud.

走向整体地狱(Monolithic Hell)

很不幸,这种简单的方式有一个巨大的限制。成功的应用都会随着时间增大,最终变得巨大。在每一个冲刺(sprint),你的开发团队实现了许多用户故事,这当然意味着添加了许多行代码。经过几年之后,原本很小、很简单的应用将会长成可怕的庞然大物。举一个极端的例子,我最近与一个开发者进行了一次谈话,他写了一个工具分析他们数百万行代码的应用中的成千上万个JAR包的依赖。我很确定这样一个怪兽是由大量的开发者经过数年的共同努力才制造出来的。

一旦你的应用变成了一个复杂的庞然大物,你的开发团队就可能生活在痛苦之中。敏捷开发的任何尝试和交付将会举步维艰。该应用的一个主要问题是过度地复杂。它仅仅是太大了以至于任何一个开发者都不能完整地理解。因此正确地修复漏洞和实现新功能将会变得困难和耗时。更糟糕的是,这形成了一个恶性循环。如果基本代码难于理解,就很难做出正确的改动。那么最终就会成为一个可怕的、无法理解的大泥球

The sheer size of the application will also slow down development. The larger the application, the longer the start-up time is. For example, in a recent survey some developers reported start-up times as long as 12 minutes. I’ve also heard anecdotes of applications taking as long as 40 minutes to start up. If developers regularly have to restart the application server, then a large part of their day will be spent waiting around and their productivity will suffer.

Another problem with a large, complex monolithic application is that it is an obstacle to continuous deployment. Today, the state of the art for SaaS applications is to push changes into production many times a day. This is extremely difficult to do with a complex monolith since you must redeploy the entire application in order to update any one part of it. The lengthy start-up times that I mentioned earlier won’t help either. Also, since the impact of a change is usually not very well understood, it is likely that you have to do extensive manual testing. Consequently, continuous deployment is next to impossible to do.

应用程序的规模也会拖慢开发进度。应用程序的规模越大,启动的时间越长。例如在最近的调查中,开发者表示启动时间长达12分钟。我也道听途说过启动时间长达40分钟的应用程序。如果开发者不得不周期性重启应用服务,那么他们一天中很大一部分时间将浪费在等待上,他们的生产力将会受到影响。

巨大的、复杂的整体应用程序的另外一个问题是它是持续部署的障碍。目前,SaaS应用通常在一天之内会多次将改动推到生成环境。对于复杂的庞然大物,这极其难处理,因为你必须重新部署整个应用来更新程序的任何一小部分。我前面提到的冗长的启动时间也将产生不利的影响。而且因为改动的影响通常不能被充分的理解,那么你可能还必须做更广泛的手工测试。最终导致持续部署几乎是不可能的。

Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements. For example, one module might implement CPU-intensive image processing logic and would ideally be deployed in AWS EC2 Compute Optimized instances. Another module might be an in-memory database and best suited for EC2 Memory-optimized instances. However, because these modules are deployed together you have to compromise on the choice of hardware.

Another problem with monolithic applications is reliability. Because all modules are running within the same process, a bug in any module, such as a memory leak, can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.

Last but not least, monolithic applications make it extremely difficult to adopt new frameworks and languages. For example, let’s imagine that you have 2 million lines of code written using the XYZ framework. It would be extremely expensive (in both time and cost) to rewrite the entire application to use the newer ABC framework, even if that framework was considerably better. As a result, there is a huge barrier to adopting new technologies. You are stuck with whatever technology choices you made at the start of the project.

当不同的模块具有资源需求冲突的时候,整体应用程序也将难以扩展。例如,某个实现CPU密集型图像处理逻辑的模块非常适合部署在AWS EC2 Compute Optimized instances。另外某个内存数据库的模块最适合部署在 EC2 Memory-optimized instances。然后由于这些模块都得部署在一起,所以你不得不在硬件的选择上做出妥协。

整体应用程序的另外一个问题是可靠性。因为所有的模块都在同一进程内运行,所以任一模块的漏洞,比如内存泄露,将会影响整个进程。此外,因为应用程序的所有实例是一致的,所以这些漏洞将会影响整个应用的可用性。.

最后但并非不重要,整体应用程序使得采用新框架、新语言极其困难。举个例子来说,假设你有两百万行使用XYZ框架写的代码。那么使用新的ABC框架重写整个应用将会是极其昂贵的(无论是时间还是花费),即使新框架相当的好。因此对于采用新技术,整体应用程序具有巨大的障碍。当你开始新的项目的时候,你将非常纠结于选择哪种技术。

To summarize: you have a successful business-critical application that has grown into a monstrous monolith that very few, if any, developers understand. It is written using obsolete, unproductive technology that makes hiring talented developers difficult. The application is difficult to scale and is unreliable. As a result, agile development and delivery of applications is impossible.

So what can you do about it?

Microservices – Tackling the Complexity

Many organizations, such as Amazon, eBay, and Netflix, have solved this problem by adopting what is now known as the Microservice architecture pattern. Instead of building a single monstrous, monolithic application, the idea is to split your application into set of smaller, interconnected services.

总而言之:你有一个已经长成可怕的庞然大物的,几乎没有开发者可以理解的,成功的业务关键应用。这个应用程序使用过时的、没有生产力的技术写成,这使得招聘优秀的开发者变得非常困难。这个应用程序难以扩展而且不可靠。因此,敏捷开发和应用交付是不可能的。

所以你能怎么办呢?

微服务 – 处理复杂性

许多组织,比如Amazon、eBay和Netflix,已经采用现在被称为微服务架构模式的方法解决了这个问题。其想法是将应用程序分割成更小的相互关联的服务,而不是构建单个可怕的整体应用程序。

A service typically implements a set of distinct features or functionality, such as order management, customer management, etc. Each microservice is a mini-application that has its own hexagonal architecture consisting of business logic along with various adapters. Some microservices would expose an API that’s consumed by other microservices or by the application’s clients. Other microservices might implement a web UI. At runtime, each instance is often a cloud VM or a Docker container.

For example, a possible decomposition of the system described earlier is shown in the following diagram:

Graph-03

Each functional area of the application is now implemented by its own microservice. Moreover, the web application is split into a set of simpler web applications (such as one for passengers and one for drivers in our taxi-hailing example). This makes it easier to deploy distinct experiences for specific users, devices, or specialized use cases.

一个服务通常实现一组独立的特性或功能,比如订单管理、客户管理等。每个微服务是一个具有六角形架构的迷你应用,其自己的六角形架构包含业务逻辑以及许多适配器。某些微服务将会暴露供其他微服务或者客户端使用的API。另外一些微服务可能实现web UI。在运行时,每个实例通常是一个云虚拟机或者一个Docker容器。

例如,前文所述的系统的一个可能的分解如下图所示:

Graph-03

应用的每个功能区域现在以微服务的方式实现。此外web应用程序分割成了一组更简单的web应用程序(一个面向乘客的,一个面向司机的)。这使得更容易为特定的用户、设备或特定的用例部署单独的服务。

Each back-end service exposes a REST API and most services consume APIs provided by other services. For example, Driver Management uses the Notification server to tell an available driver about a potential trip. The UI services invoke the other services in order to render web pages. Services might also use asynchronous, message-based communication. Inter-service communication will be covered in more detail later in this series.

Some REST APIs are also exposed to the mobile apps used by the drivers and passengers. The apps don’t, however, have direct access to the back-end services. Instead, communication is mediated by an intermediary known as an API Gateway. The API Gateway is responsible for tasks such as load balancing, caching, access control, API metering, and monitoring, and can be implemented effectively using NGINX. Later articles in the series will cover the API Gateway.

Graph-05

每个后端服务暴露一套 REST API,大部分服务调用其他服务提供的 API。例如司机管理模块使用通知服务告知空闲的司机可能的订单。UI 服务调用其他服务来渲染 web 页面。服务也可能使用异步的、基于消息的通信方式。服务间通信将会在本系列后面的文章中详细讨论。

某些 REST API 是暴露给司机和乘客使用的移动 app 的。然后 app 不能直接访问后端服务,其间的通信是通过称为 API 网关的媒介传递的。API 网关负责负载均衡、缓存、访问控制、API 测量和监控,该模块可以使用 NGINX 有效的实现。本系列后面的文章将会讨论 API 网关。

Graph-05

The Microservice architecture pattern corresponds to the Y-axis scaling of the Scale Cube, which is a 3D model of scalability from the excellent book The Art of Scalability. The other two scaling axes are X-axis scaling, which consists of running multiple identical copies of the application behind a load balancer, and Z-axis scaling (or data partitioning), where an attribute of the request (for example, the primary key of a row or identity of a customer) is used to route the request to a particular server.

Applications typically use the three types of scaling together. Y-axis scaling decomposes the application into microservices as shown above in the first figure in this section. At runtime, X-axis scaling runs multiple instances of each service behind a load balancer for throughput and availability. Some applications might also use Z-axis scaling to partition the services. The following diagram shows how the Trip Management service might be deployed with Docker running on AWS EC2.

Graph-02

微服务架构模式对应扩展立方体(Scale Cube)的 Y 轴扩展,扩展立方体是《The Art of Scalability》一书中描述可扩展性的 3D 模型。此外还有两个扩展维度,X 轴扩展表示在负载均衡器后面运行多个相同的应用程序副本,Z 轴扩展(数据分割)表示使用请求中的某个属性(例如数据表主键或用户 id)来路由请求到特定服务器。

应用通常综合使用三种扩展。Y 轴扩展分解应用程序到微服务,就像上图展示的那样。在运行时,为了吞吐量和可用性,X 轴扩展在负载均衡器后面运行多个服务的实例。某些应用也可能使用 Z 轴扩展分割服务。下图展示了如何使用 Docker 将订单管理服务部署在 AWS EC2 上。


Graph-02

返回顶部
顶部