With the increasing pressure of my factory’s business demand and the continuous improvement of infrastructure, the micro-service transformation of system architecture has been officially put on the agenda. Starting with the target architecture blueprint design of the microservices transformation, the architecture team had a full two days of intense discussion and identified many business boundaries. In this process, I learned a lot of knowledge, combined with some previous experience here to summarize and share.





That’s what microservices does

00 preface

As for the system design of why to build microservices architecture, how to build microservices architecture, there are many articles on these issues, I also have an article on related topics, interested students can refer to it.

The theme of this paper is to introduce how to build a perfect target architecture in the initial stage of micro-service transformation. All future transformation actions are close to this goal, and the target architecture plays a guiding role in the implementation of micro-service transformation.

The material source of this article is the process of the micro-service transformation target structure of our factory, and the record of this unforgettable and brain-burning process may be a running account after writing. I hope that when I read this article after the micro service transformation is complete, I will find that all the architectural designs at the beginning are in place, and it is almost perfect!!

The members of the seminar come from the architecture group of the technical department and major developers from each business capability development group, and huawei software experts are also invited to provide on-site guidance. From participants, both to overview the current status of the architect, also has the development experience of a line of developers, most of the business scenario (cover), in everyone’s heart has a beautiful vision, everyone thought collision fusion, absorb their excellent scheme, finally formed a relatively perfect target architecture.

01 Implementation plan of micro service transformation

Micro-service transformation is a long process. Seen the transformation process of some companies, it takes about 2 years to transform a similar scale system. Therefore, in order to ensure that the whole micro-service transformation process can be carried out in an orderly manner, it is necessary to have a practical plan. Our plan is as follows:

  1. Provide the company’s goal architecture blueprint.
  2. Frame selection and infrastructure improvement.
  3. Formulate the development specification of micro-service transformation.
  4. Typical project practice, summing up experience.
  5. Revision of architecture specifications.
  6. Large-scale micro-service transformation has been implemented.

It seems that this is a relatively stable plan. After such a transformation process of microservices, all our business systems are more reasonable in structure, with reduced coupling degree between each other, clear business boundaries, and close to a tree structure from top to bottom.

02 Architecture Status

We are a third-party payment company. It should be easy for students to imagine a general scope of business system and internal system structure. We can also see the system architecture diagram of the major third-party payment companies on the Internet. Although we are a small payment company, we have everything. However, since they were all business driven in the early stage of development, many systems emerged, many of which were independently constructed. It was inevitable that the system construction was a bit bloated, and there were a large number of unreasonable calls between many systems. When drawing the call diagram, it looked very messy. And many functions are repeated construction, waste of resources.





Application Architecture Status

In the current architecture, a part of the system has been reconstructed, but these reconstructions are relatively independent, and there is no unified specification. The design of the refactoring system depends entirely on the knowledge horizon of the principal designer and his understanding of the business. In the selection of technology is also different, the general choice is relatively familiar with and grasp the larger framework. The architecture design of each system is also different. Several recently built systems basically adopt the microservices design pattern, some adopt THE SOA architecture, some just do the separation of the design before and after the system, and some projects are completely single structure.

Although we began to have a certain plan for the system construction, with the rapid and savage development of business, we blindly pursue fast and give in to business design. As a result, the business boundaries of both the restructured and reconstructed systems and the newly built systems are not obvious, and repetitive functions are being developed between them, which is relatively scattered, and the system is not built with a sense of unity.

The main problems caused by this situation are:

  1. New product builds are slow and completely inadequate for rapid business growth.
  2. It is difficult to automate operation and maintenance.
  3. It is difficult to increase performance through capacity expansion.

Through the design idea of micro-service architecture, guide us to carry out system transformation. The basic services are stripped from each business system to form a unified service capability; Various support systems to achieve high performance, high availability of infrastructure gradually improved; Enables business systems to focus more on business logic implementation. Using the guiding ideology of domain-driven design, the business boundaries of each system are clarified. After such planning and design, it should be possible to achieve a perfect upgrade of the system architecture.

03 The main issues at issue

The microservices architecture points the way conceptually, laying down a few important design principles: keep services as small as possible, deploy independently, deploy autonomously, and operate. These concepts need to be implemented in practice. Due to the differences in understanding and the various current situations of companies, each company must implement different micro-service architectures with its own characteristics. After all, the architecture design serves business modules. Therefore, our factory is also discussing how to implement the micro-service architecture in line with our own company characteristics.

There were several controversial topics during the discussion, summarized here:

  1. Where is the boundary between low-level capabilities and upper-level products? To what extent are the underlying capabilities abstracted, and do you care about the upper-level product business logic?
  2. The split versus merge game.
  3. Whether the design on the business module allows a single point.
  4. How much change can be made in organizational structure and division of labor.

In fact, the previous two points are the division of business boundaries. The first point is the vertical boundary after stratification, and the second point is the horizontal boundary. For the first point, let’s take the top-up function as an example:

The standard recharge process is 1. The user’s bank card is deducted (payment interface); 2. Internal account accounting. The detailed steps are not explained here. Students familiar with payment business should know that there are various payment methods and internal accounts (the standard top-up account is the user’s cash account). If the standard top-up, these two steps are also the standard process; If there is a special business, the recharge is charged to the commission account, should the recharge of such special business be realized in the recharge center? Stay in third-party payment companies for a long time, you will find that there are a variety of standard products, but also many customized products.

Our conclusion is that the standardized functions are supported by the underlying services to provide standard capabilities for the product layer, and have strong features of individual business, which are encapsulated and realized by the product layer directly calling the capabilities of the lower layer.

On the second point, some of you might wonder, isn’t the principle of microservice architecture to keep services as small as possible, to achieve high cohesion and low coupling? Why are there mergers? My understanding is that this principle only applies to complete business logic design. There are also some basic business irrelevant components to be realized in system construction. These common services (such as unified serial number and unified session management) should be abstracted and implemented uniformly and invoked by business system. There are also data that are very similar in terms of management and use, which can be managed together to provide services uniformly.

In business design, the design principle of microservices is to avoid single point modules. Fully distributed and highly cohesive services have many benefits, scattered pressure and little influence on each other, but they need to be managed separately. In fact, these benefits are relative. In a company with a high technology average, the cohesive system is relatively good, and the various technologies can be harnessing well. For example, whether the payment order system should be dispersed to each product system, or unified to make an order center, so that when the performance needs to be improved, when some asynchronous processing, can be unified in one place to achieve performance improvement.

Martin Fowler’s demonstration of microservices shows that microservice architecture is not only a system architecture, but also a guide for personnel organization architecture. The team should be as full stack as possible to achieve high cohesion and low coupling. In order to reduce the inefficiency caused by cross collaboration between departments and organizations, we are responsible for each product, not a deliverable project. The whole life cycle of the product should be maintained by the team. In this case, the original organizational structure also needs to be adjusted under the implementation of micro-service transformation, which requires the support of leaders.

There is not much discussion on the support system and infrastructure. The underlying operation and maintenance services are relatively standard, and most of them have been completed and are now in the stage of improvement and optimization.

To sum up, architecture design itself is a game of tradeoffs, whether it is the popular microservices architecture or other architectures such as SOA before it. The best architectural design is to fit the company’s own business development and planning, as well as the organizational structure, which may hinder the process of microservitization, but from the practical point of view, how much these businesses and organizations can make changes for microservitization, also need to be considered. We are not doing radical reform, micro service transformation should be a natural, step-by-step optimization process.

It was the first time to participate in such a large scope of architecture design, and I found that there were too many things to weigh, whether some design principles should be adhered to.

04 Target Architecture (Blueprint)

Finally, I made the following architectural design drawing based on the consensus reached by everyone and my understanding of the business:





The target architecture

This article is my understanding of micro-service transformation and business restructuring, and does not represent the formal structure of the company. Some designs are not good or bad, but the key is to weigh the pros and cons and evaluate the situation.