Editor's Note |
The Author: Chris Richardson, is the world's leading software guru, author of classic works of art "POJOS IN ACTION" a book, but also cloudfoundry.com original founder, Chris Richardson and Martin Fowler, Sam Newman, Adrian Cockcroft, etc. and called world's top ten software architect.
Chris Richardson whole series micro service 7:
1. micro-analytical services architecture concept
2. Construction of micro Services Architecture: Using the API Gateway
3. Inter-depth micro Services Architecture interprocess communication (this article)
4. viable options for service discovery and practice cases
The event micro drive data management services
6. Select Micro Services Deployment Strategy
7. monomer transformed into micro-services application (this article)
The use of micro-service remodeling Overview
The monolithic applications into a micro-services application process is the process of modernization for decades developers have been working on this. Thus, when the application for the reconstruction of micro-services, we can learn from the idea of them.
First, do not rewrite the code on a large scale. Massive rewrite the code means that you need to focus all development efforts, a new application built from the ground-based micro services; it sounds attractive, but full of risk, and may end in failure. As Martin Fowler says, "large-scale rewrite the only way to ensure that only massive!"
Instead, the strategy should be taken step by step reconstruction monomer applications. And gradually build an application, and the application made of single micro-services to run in parallel; with the passage of time, the original application functions implemented by the shrinking monomer, or finally disappeared completely, or into a micro-services. This method, although challenging, but the risk is much smaller than the large-scale rewrite the code.
Martin Fowler will be the application of modern strategy called "killer application." The name is derived from the killer vine rainforest. Killer vine epiphytic tree, directly above the crown; the tree died, leaving a vine tree. Modern applications also follow this pattern. New applications of micro-services constitute around legacy applications, which eventually completely ceased to exist.
Next, learn about the different implementation strategies.
Strategy One: Stop digging
The first rule of digging pointed out, if you find yourself out of the hole, stop immediately. This advice also applies to the single application difficult to manage. In other words, should stop the monomers applications continue to become larger, that is, when implementing new functions and should not add the code. Instead, the idea of this strategy is that this part of the new micro-code development called independent service. The following figure shows the system architecture using this method.
In addition to new services and legacy applications, this system also includes two other components. One is a request routing, processing incoming (HTTP) requests, API gateway described in previous articles similar. The routing function transmits the new request corresponding to the new service request is sent to an existing legacy application monomers.
Another component is the glue code (glue code), responsible for integrating micro and single service application. Micro service rarely exist in isolation, usually single application needs to access data owned. Glue code present in the monomer or micro application services, or both, is responsible for data integration. Micro service data using glue code for reading and writing monomers have application.
Micro data service can access single applications in three ways:
- Remote API call provided by the single application
- Direct access to application data monomers
- Maintenance copy of the data, synchronized with the database application monomers
胶水代码也被称作防崩溃层（anti-corruption layer）。对于拥有自己全新领域模型的微服务，胶水代码能够阻止其受到遗留单体应用的领域模型的污染，并且为这两种模型提供转换。防崩溃层这一术语最早出现于 Eric Evans 撰写的必读书 Domain Driven Design 中，并被提炼成为白皮书。开发防崩溃层是项不平凡的工作，要想远离单体应用的泥淖，创建防崩溃层必不可少。
以轻量级微服务的方式实现新功能有诸多优点。它能够防止单体应用变得不可管理。微服务能够独立于单体服务进行开发、部署和扩展。采用微服务能让开发者切身感受其好处。
然而，这一方法并没有解决单体应用的问题。要想解决这些问题，需要分解单体应用。
策略二：拆分前端和后端
缩小单体应用的策略之一是将表示层（presentation layer）与业务逻辑和数据访问层分离。典型的企业应用包括至少三类组件：
- 表示层：处理 HTTP 请求并实现 (REST)API 或基于 HTML 的 Web UI。对于包含复杂用户接口的应用，表示层往往是代码的实体部分。
- 业务逻辑层：应用的核心，实现业务逻辑
- 数据访问层：访问诸如数据库和消息代理这样的基础架构组件
在表示逻辑与业务和数据访问逻辑之间，有着清晰的间隔。业务层的粗粒度的 API 由若干方面组成，内部封装业务逻辑组件。这个 API 是一道天然分界线，将单体应用分割成两个较小的应用。一个应用包含表示层，另一个应用包含业务和数据访问逻辑。拆分后，表示逻辑应用对业务逻辑应用远程调用。下图展示了重构前后的构架。
以这种方式切割单体应用有两大好处。首先，它使得这两个应用的开发、部署和扩展用各自独立。尤其是，它使得表示层的开发人员能够快速迭代用户接口，轻松进行 A|B 测试。其次，它暴露了远程 API，能够被微服务调用。
这种策略也只是部分解决方案，很有可能其中一个应用或两个应用变成难以管理的单体应用。这时需要使用第三种策略来消除剩余的单体应用。
策略三：提取微服务
第三种重构策略是将单体应用内现有的模块转变为独立的微服务。每当提取模块并将其转化为服务，单体应用就会收缩。一旦转化了足够的模块，单体应用也不再是问题，它或者彻底消失，或者小到成为另一个微服务。
为需要转化为微服务的模块设置优先级
大型、复杂的单体应用由数十甚至数百个模块组成，每个都是提取的对象。要弄清楚哪些模块首先被转化，往往具有挑战性。从易于提取的模块开始是个好方法，它能让开发者熟悉微服务和提取过程。然后就应该转化能从中获益最多的模块。
鉴于把模块转变为微服务非常耗时，一般会根据获益程度来给模块排序。从频繁更改的模块开始会让用户收获不菲。一旦把模块转化为微服务，也就能独立开发和部署，从而加速开发进度。
将资源需求大不相同的模块优先转化，也颇有好处。例如，把内存数据库模块转化为微服务，能够被部署在大内存主机上。同样，将实现计算算法的模块提取出来也是非常值得，这一微服务能够部署在拥有大量 CPU 的主机上。通过将对资源有着特殊需求的模块转变为微服务，应用能够易于扩展。
找出哪些模块需要优先提取后，找出现有粗粒度的边界（即分界线）也大有裨益。这些边界让模块转变为微服务更加简单、省力。例如，通过异步消息与应用的其它部分通信的模块能够相对省力、简便地转化为微服务。
如何提取模块
模块提取的第一步是定义模块和单体应用间的粒度接口。由于单体应用和微服务互相需要对方拥有的数据，因此更像是双向 API。由于模块和应用其它部分之间存在着互相依赖和细粒度的交互模型，因此实现这样的 API 充满挑战。对于重构微服务，通过领域模型实现的业务逻辑尤为挑战，开发人员需要大刀阔斧地修改代码来打破这些依赖。
粗粒度接口一旦完成，模块也就变成了独立的微服务。要做到这一点，开发人员必须编写代码，能够让单体应用和微服务通过 API 通信，API 使用进程间通信（IPC）机制。 下图展示了重构前、重构中和重构后的不同架构。
In the picture, the module Z will be reconstructed, it used the Y component modules, as well as its components are using the module X. The first step is to define a reconfigurable coarse-grained API. The first interface is an internal interface module X used to wake up module Z. The second interface is the use of an external interface module Z, Wake module Y.
The second step is the reconstruction of the module into separate micro-services. Internal and external interfaces through code IPC mechanisms of implementation, the developer may only need to micro-module Z and services supporting frame (Microservice Chassis framework) be combined to build micro-services. Micro-service support framework for dealing with the cutover related issues, such as service discovery.
Upon completion of the extraction module, to obtain the equivalent of a micro-services, it is possible to independently develop applications and other micro-monomers, the deployment and expansion. If the service code to be rewritten from scratch micro, micro-integrated services and applications API code monomer becomes crash-proof layer between the two field models. Each reconstruction component, as the direction of the micro services a step forward. Over time, the single application gradually disappear, micro services are more and more.
to sum up
Migrate existing applications to the micro-service architecture monomer is a modern application. To achieve this result it does not need to rewrite the code from scratch, on the contrary, only progressively applied to a set of reconstructed micro service. There are three strategies which can be adopted: the use of micro-services to implement new features and components representing business and data access component split, and the modules within existing applications into a micro-services. Over time, a large number of micro-service formation, the team's agility and efficiency will be enhanced.
Reprinted from the article: http://blog.daocloud.io/microservices-7/