The author | Emac
Almond Doctor Architect and platform group leader, focusing on microservices and DevOps.
A popular word in the technology circle is that those who break away from business and talk about architecture are playing rascal. Do you ever miss writing a thousand lines of code by hand in an afternoon, when new requirements are slow to respond and overtime is the norm? Divide and conquer is often the most effective approach when faced with a behemoth (monolithic apps) that is constantly gobbling up team time. Today I’d like to talk to you about my understanding and first-hand experience of how small companies can transform themselves into micro-services.
1. Introduction to micro services
The most authoritative definition of Microservices is described by Martin Fowler, the father of Microservices, in the Microservices Resource Guide:
In short, the microservice architectural style 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. — James Lewis and Martin Fowler
Note the three key words: small, independently deployable, and automated deployment. Small corresponds to the micro of microservice. Many students who are first exposed to microservice tend to have an understanding of micro at the implementation level, thinking that a Small number of codes means micro. However, in fact, the micro here is more reflected in the logical level. An important design principle for microservices is share as little as possible. What does that mean? That is to say, each microservice should be designed with clear boundaries and no overlap, and the data should be exclusive and not shared, which is often referred to as high cohesion and low coupling. To ensure small, can be truly regulated deployable. The key to implementing automated Deployment is the DevOps culture, see Fowler’s other article on DevOps. It should be noted that as business complexity increases, a microservice may need to be split into more fine-grained microservices, for example, a simple order service at the beginning, and then gradually split into other services such as clearing, payment, settlement, reconciliation and so on.
In essence, microservices offer more thoroughly distributed features, such as heterogeneity and isolation, at the expense of greater consistency and deployment complexity than monolithic applications. Corresponding to CAP theory, is to replace Partition with Consistency. The heterogeneity is easier to understand, and by defining a uniform API specification (typically in the REST style), each microservices team can choose the best technology stack for its own capability matrix, rather than everyone having to use the same technology stack. Strong isolation means, for a typical application of monomer, isolation, highest can only reflect to the module level, due to the warehouse, sharing the same code module boundaries often vague, need define human a lot of rules and standards to ensure that the good isolation, but no matter how stressed that a negligence, will generate “provocative” behavior, time is more long, maintenance of isolation, the higher the cost. When it comes to microservices, the cost of “crossing the line” increases dramatically with built-in application-level isolation. Without any specification, the architecture itself guarantees isolation.
On the other hand, due to the distributed architecture, micro-services can no longer simply ensure strong consistency through database transactions, but through message middleware or some transaction compensation mechanism to ensure the final consistency, such as the likes of wechat moments and the logistics status of Taobao orders. Secondly, in the micro-service stage, with the surge of the number of applications, one release often involves multiple applications, and the diversity of deployment modes brought by heterogeneity puts forward higher requirements on the team’s operation and maintenance level, especially the automation level, and the boundary of operation and peacekeeping development is further blurred.
After talking about the background knowledge about microservices, now I will get to the main topic of today, facing the rapid growth of business needs, how small companies to carry out microservice transformation? The following is the background of the whole process of micro-service transformation led by me in Almond. I will give you a brief introduction of the general idea of our micro-service transformation and the technology selection process of core middleware.
2. Project background
First, introduce the background of micro-service transformation. At the beginning of last year, after more than 2 years of product iterations, the whole backend application became a monolithic Application in a typical sense: 1. The business modules are intertwined with overlapping codes and patches. 2. Every change needs a full release, even if it is a copy modification, which greatly slows down the iteration speed.
At the same time, as the company’s e-commerce business is becoming more and more complex, the old business model is increasingly difficult to meet new demands, and it is urgent to reconstruct the original order module or extract an independent order service to support it. After much deliberation, we chose the latter. Since it was the first time for the team to try micro-service, and the initial staff was limited (one person leading, many people cooperating), we finally decided to take a more practical and improved route:
1. Minimize intrusion on existing applications
2. Prefer mainstream microservices frameworks
3. Perform necessary microservice governance
The first one sets the tone of the transformation, reduces the risk that the scheme cannot be implemented, and ensures the overall feasibility of the project. The second lets us stand on the shoulders of giants, not reinvent the wheel, and focus on the problem, not the tools. Article 3 Reduce the scope of projects, avoid excessive engineering, so as to raise troops through war and not to fight useless wars.
The following figure shows the current overall architecture of Almond microservices.
3. Basic framework
The basic framework we choose is Spring Boot. Spring Boot is a container – free, XML – free application framework provided by the Spring community. In contrast to standard WAR package-based Web applications, Spring Boot applications can run directly in Java-JAR mode, meaning they no longer need to be deployed to a separate Web container (such as Tomcat) to run. The mechanism behind this is simply that when a Spring Boot application is started, an embedded Web container (Tomcat by default) is started after the core framework classes are loaded, and the various configuration classes and beans of the application itself are loaded. That is, instead of container package application, application package container. Because of this feature, Spring Boot is ideal for developing microservices, which is literally what Spring Boot was born for.
Some of you might ask, aren’t there Dubbo and Spring Cloud? Dubbo is the first generation of Alibaba’s open source RPC framework, which was released in version 2.0 in 2011, three years before Martin Fowler proposed the concept of microservices in 2014. It is possible to develop microservices with Dubbo, but this is like developing Spring beans with the EJB specification. The biggest problem with Dubbo is the slow upgrade. The last release was in October 2014. Spring version 2.5.6.sec03 is supported, and Spring 5 is coming soon.
Spring Cloud is arguably the best and most complete microservices framework in the Java community (there is no one). The bottom layer is also Spring Boot. According to the beginner’s guide of Spring Cloud, you can build a complete set of microservices in minutes. It is ideal for a transformative, but not improved, microservice transformation because non-Spring applications are difficult to integrate.
On the other side of the coin, the choice of Spring Boot meant a lot of customization to compensate for Spring Boot’s lack of microservice governance capabilities, such as the registry, configuration center, and authorization center that will be covered in the next article. Feel free to leave a comment and share your thoughts and opinions.