Microservices architecture is now a must-talk topic when it comes to enterprise application architecture. Microservices are also popular because they have many advantages compared to previous application development methods, such as being more flexible and better able to adapt to the current environment of rapidly changing requirements. Microservices architecture is now a must-talk topic when it comes to enterprise application architecture. Microservices are also popular because they have many advantages compared to previous application development methods, such as being more flexible and better able to adapt to the current environment of rapidly changing requirements. This paper will introduce the evolution, advantages and disadvantages of microservice architecture and the design principles of microservice application, and then focus on the capabilities and problems that need to be provided and solved as a “microservice application platform” to better support enterprise application architecture. The micro-service platform is also a platform product that I am currently participating in and is still in the development process. Based on SpringCloud, the platform is gradually incubated by combining puyuan’s years of understanding of enterprise applications and product design experience. 1. Evolution of microservices architecture
In recent years, we have all realized the benefits of the Internet, mobile Internet, as IT professionals, feel the Internet benefits, at a time of life at the same time, in the work is from the Internet may feel some pressure, IT is our traditional enterprise’s construction is also an urgent need to transform IT, need for external customers, We also need to cope with the rapid change of the external environment and make rapid innovation, so our IT architecture also needs to learn from Internet enterprises and make corresponding improvements to support the digital transformation of enterprises. We look at the application architecture evolution process, recall how micro service architecture evolved step by step, is the earliest application is a single piece of architecture, then in order to have a certain extension, and reliability, there will be a vertical structure, namely to add a load balancing, followed by the SOA more fire a few years ago, mainly about how to integrate and exchange between application systems, Now the microservice architecture is to further explore how an application system should be designed to be more flexible and efficient in development and management. The basic idea behind microservices architecture is to “build applications around business domain components that can be independently developed, managed, and accelerated”. Second, the benefits of microservices architecture
We summarize four advantages, which are as follows: Each microservice component is simple and flexible, and can be deployed independently. Applications no longer need a huge application server to support them. It can be more focused and professional with a smaller team, which in turn is more efficient and reliable. Microservices are loosely coupled to each other, highly cohesive within the microservices, and each microservice is easily extended on demand. Microservices architecture has nothing to do with language tools, just choose the appropriate language and tools to accomplish business goals efficiently. Seeing this, you will feel that the microservice architecture is quite good, but there will be some questions, what is a microservice architecture application? How to design a microservice architecture application? Let’s take a look at our recommended design principles for microservices applications. 3. Four design principles for microservice applications
We recommend four principles to you: AKF splitting principle Front and back end splitting stateless Service Restful Communication style 1.AKF splitting principle
AKF extension Cube (see The Art of Scalability) is an abstract application of three dimensions to The Scalability of a company called AKF. Theoretically, according to these three expansion modes, a single system can be extended indefinitely. X-axis: refers to horizontal replication, which is easy to understand. It means that a single system runs several instances to make a cluster and load balancing mode. Z-axis: it is based on similar data partition. For example, an Internet taxi-booking application suddenly fails, the number of users increases rapidly, and the cluster mode cannot hold up. Then, data partition will be carried out according to the region requested by the user, and more clusters will be built in Beijing, Shanghai, Sichuan, etc. Y-axis: This is what we call the microservices unbundling model, which is based on different services. Scenario description: For example, the taxi application was divided into multiple clusters when one cluster could not support, but the user surge was still insufficient. After analysis, it was found that there was a lot of traffic from passengers and car owners, so the taxi application was split into three passenger services, car owner services and payment services. The three services have different business characteristics and are maintained independently, each of which can be extended again on demand. 2. Separate the front and rear ends
The principle of front and back end separation, simply speaking, is the separation of front-end and back-end code, which is technically separated. We recommend that it is best to directly deploy in the way of physical separation to further promote a more complete separation. Don’t go back to the old server-side template techniques, such as JSP, where Java, JS, HTML, and CSS are all stacked into a single page, and a slightly more complex page cannot be maintained. This separation mode has several advantages: the technology of the front and back end is separated, and the respective experts can optimize their respective fields, so that the user experience optimization effect of the front end will be better. In split mode, the front and back interfaces are clearer, leaving interfaces and models, while the back interfaces are cleaner and easier to maintain. Front-end multi-channel integration scenario is easier to achieve, back-end services do not need to change, using unified data and model, can support front-end Web UI mobile App access. 3. Stateless service
For stateless services, let’s start with what state is: if a piece of data needs to be shared by multiple services in order to complete a transaction, that data is called state. Services that in turn rely on this “stateful” data are called stateful services, and vice versa. The stateless service principle does not mean that stateless services are not allowed in microservices architecture. What it really means is that stateful business services should be changed into stateless computing services, and stateful data should be migrated to the corresponding “stateful data services”. Scenario Description: For example, the data cache and Session cache established in local memory should be transferred to distributed cache for storage in the current microservice architecture, so that the business service becomes a stateless computing node. After migration, on-demand dynamic scaling can be achieved, and micro service applications can dynamically add and delete nodes at runtime, so there is no need to consider how to synchronize cached data. Restful communication style
As a principle, it should be the “stateless communication principle”. Here we directly recommend a preferred Restful communication style in practice because it has many advantages: stateless protocol HTTP has inherent advantages and is very scalable. For example, if you need secure encryption, there are mature solutions available such as HTTPS. JSON message serialization is lightweight and simple, readable by humans and machines, low learning cost, and friendly to search engines. Regardless of the language, the popular languages all provide mature Restful API frameworks, which are more complete than other RPC frameworks. Of course, in some special business scenarios, other RPC frameworks, such as THRIFT, AVro-RPC and GRPC, are also required. But for the most part, Restful is good enough. 4. Problems caused by microservice Architecture If the four principles mentioned above are fulfilled, it can be said that a microservice application is built, and it does not feel complicated. But in fact, micro-services are not a panacea, and there are pros and cons. Let’s take a look at the problems brought by the introduction of micro-services architecture.
Dependent service changes are hard to track, and what if other teams’ service interface documentation is out of date? Dependent services are not ready to validate the functionality I developed. Some modules are built repeatedly, across teams, across systems, and across languages. Microservices amplify the problems of distributed architecture, such as how to handle distributed transactions? What if the dependent service is unstable? The o&M complexity increases sharply, for example, the number of deployed objects and monitoring processes increases. We should have encountered all of these problems before, and have some solutions, such as providing tools and frameworks for document management, service governance, and service simulation; Unified authentication, unified configuration, unified log framework, and distributed summary analysis are implemented. Global transaction scheme and asynchronous simulation synchronization are adopted. Build continuous integration platform, unified monitoring platform and so on. Finally, we realized that we needed a microservice application platform to solve these problems as a whole. Five, 19 implementation of micro service platform practice 1. Three basic environments of enterprise IT construction Let’s first take a macro look, an enterprise IT construction is very important three basic environment: teamwork environment, personal basic environment, IT infrastructure.
Team collaboration environment: This is primarily the domain of DevOps, responsible for everything from requirements to planned tasks, team collaboration, to quality management, continuous integration, and release. Personal basic environment: it is the micro-service application platform introduced in this paper. Its main goal is to support the design, development and testing of micro-service applications, business data processing during operation and application management and monitoring. IT infrastructure: Implementations of various operating environments such as IaaS (VM virtualization) and CaaS (container virtualization) are commonly referred to. 2. Overall architecture of micro-service application platform
The overall architecture of microservice application platform is mainly divided from the dimensions of development integration, microservice operation container and platform, runtime monitoring governance and external channel access. Development integration: it is mainly to build some tools and warehouse runtime required by a micro-service platform: there should be a micro-service platform to provide some basic capabilities and distributed support capabilities, and our micro-service operation container will run on this platform. Monitoring governance: it is committed to unified monitoring and configuration of managed microservices at runtime. Service gateway: it is responsible for integrating with front-end WEB applications, mobile apps and other channels, conducting careful authentication on front-end requests, and then routing and forwarding. 3. Running view of the micro-service application platform
Refer to the figure above. During the operation period, as a platform and business system with micro-service architecture, besides business application itself, platform level services such as access service, unified portal and basic service are required to ensure the reliable operation of the business system. The common services in the figure are some of the optional services that need to be used in the business process. 4. Design objectives of the micro-service platform
Micro service platform’s main goal mainly is to support the service application of whole life cycle management, from requirements to design development and testing, the run-time of business data processing and application of management and monitoring, follow-up will be cut from several important application lifecycle stage, combined with the design principles and problems of the previously mentioned, introduces the platform’s ability to provide support. 5. Microservice development: front-end, back-end, hybrid
Let’s take a look at screenshots of some of the development tools for our micro-services application platform, EOS8.0, to see what key capabilities were provided during development. The previous design principle mentioned a separation of the front and back ends, so our development environment currently supports the creation of front-end projects, back-end projects, and hybrid projects. Front-end projects and back-end projects correspond to the principle of front-end and back-end separation. The development tools and frameworks integrated in the platform can be used to achieve the separation of front-end and back-end development. Continuous integration tools can be used to easily compile and package front-end and back-end projects into independent programs. Hybrid projects are reserved for compatibility with traditional patterns, providing a transition for enterprise applications to evolve into microservices architectures. 6. Service Contract and API Management For the dependency management problems brought by the aforementioned micro-services, we can solve the problem through the API management capabilities provided by the platform. When it comes to API management, it starts with service contracts. Platform development tools provide convenient service release ability, can quickly publish business functions to the outside, generate service specification contract, of course, can also design the service contract, according to the contract to generate the default implementation code of the service. It is important to emphasize that the service contract we mentioned is similar to the WSDL description of a Web Service, which mainly describes the input and output specifications of the service interface and other specifications related to service invocation integration.
7. Service contracts with service simulation service contract, we will be able to automatically generated according to the contract documents and service simulation test environment, so that developers can easily get to rely on the service changes, able to timely adjust their own program according to rely on the service changes, and the ability to easily simulate test validation.
Generate mock services from the contract, often referred to as service baffles, so that we can perform tuning tests even if other services we rely on do not provide functionality. 8. Service contracts and Service Choreography
With service contracts, you have input and output specifications for service interfaces, and restful service choreography becomes possible. In the contract standards we designed, we also defined things related to invocation integration, such as transaction patterns supported by the service, and so on. With these conventions, business service processes can be choreographed in a simple graphical manner. Orchestration can greatly simplify the complexity of distributed service invocation, such as synchronous, asynchronous, asynchronous simulation synchronization, timeout retry, transaction compensation, etc., all completed by service orchestration engine, no longer completely dependent on the old master’s coding ability. Service choreography plays a great role and significance. It can quickly combine and publish the micro-service capabilities already provided, which is very suitable for rapid business innovation. However, it is important to note that logical flow is a business process choreographed, as simple as possible, at a glance to understand the meaning of the business. Business rules are recommended to be encoded internally within the service. Don’t let our “logic flow” graphical service choreography completely replace coding, as you might go to the other extreme and design a logic flow diagram that looks like a spider’s web, which is a disaster. 9. Microservice containers
Let’s take a look at the logic diagram of the microservice running container, and you can see that we need to do a lot of things to build a microservice architecture, a reliable and efficient microservice application. Without a unified microservice container, these capabilities would need to be built in each microservice component, and would be varied and difficult to integrate. With a unified microservices runtime container and some common infrastructure services, the problem of duplication of components in the microservices architecture mentioned earlier has been solved. 10. Tripartite capability Integration Description Our API management Contract document API simulates our tool chain with Swagger integrated. SpringCloud is the foundation of the microservices application platform, and its capabilities are used to support basic solutions from container framework to registration discovery to security authentication. Here’s a quick look at some of the open source frameworks and tools we’ve integrated.
SpringCloud’s positioning in microservice platform is the basic framework. This paper focuses on introducing some design principles and solutions in the landing process of an enterprise-level microservice platform. Specific Spring Cloud related technologies will not be introduced in this article, you can view the relevant articles in our official account. 11. The service registers and discovers routes
Next, we talked about registration and found that in the past, when a single block of applications called each other, it was enough to configure an IP address. However, under the microservice architecture, there are many service providers, and manually configuring IP addresses has become a non-feasible thing. The solution of automatic service registration discovery solves this problem. Our service registry discovery capability relies on the SpringCloud Eureka component. When the service is started, it will register the service to be published with the service registry. When it is running, if it needs to call the interface of other micro-services, it must first obtain the address of the service provider from the registry. After getting the address, it will be routed through the simple load balancing period inside the micro-service container. In general, the microservices in the system are called through this client-side load pattern, otherwise many load balancing processes would be required. Service invocations across business systems can also be routed in this decentralized manner. Of course, the SOA model, by the centralized service network management system to manage the call between systems is another choice, to be combined with the IT status and needs of the enterprise to decide. 12. Unified authentication
In terms of Security authentication, we make Security tokens based on Spring Security, Auth2 and JWT(Json Web Token) to achieve unified Security authentication and authentication, so that micro-services can be isolated and secure communication as required. In the follow-up, in terms of unified authentication and permissions, our products will launch more perfect and well-expanded micro-service components, which can be used as public authentication and authentication services for micro-service platforms. Again, authentication must be a public service, not a separate system. 13. Log and flow design
As a micro service application platform in addition to support the development and operation of the technical components and framework, we also provide some ops friendly experience summary, we look at the log we recommend and implement water, first to see the log, platform will default back to provide log there are three main kinds, system logs, the engine log and trace log. With these logs, we can obtain some key information to locate problems when they occur. If problems can be traced to the source, the design of these serial numbers on the right is also very important. The log and various serial numbers can help us quickly locate the specific time, place and relevant information of the problem, and quickly restore the whole link of business transactions. The details of these log and flow processing, for the system operation and maintenance problem location has a very great help, without these useful log content, ELK log collection suite no matter how beautiful, collect a pair of garbage log is useless. Often open source frameworks simply provide a framework for developers to play with, while designing a platform must consider directly providing the basic capabilities of a unified specification. 14. Centralized configuration management
In the microservice distributed environment, a system is divided into many microservices. Therefore, it is necessary to say goodbye to production or manual modification of configuration and configuration in operation and maintenance. Centralized configuration management is required to improve o&M efficiency. There are two types of configuration files: static configuration before running and dynamic configuration during running. Static configuration is usually set up before compiling the deployment package. Dynamic configuration refers to system variables or service parameters that need to be adjusted during system running. To achieve centralized configuration management, you need to pay attention to the following points. Is the configuration and media separation, which needs to be controlled through the formulation of specifications. Never put your configuration in a Jar. To adopt a unified configuration framework, it is necessary to have a configuration center to manage the configuration information in the business system in a unified way, which requires a platform to provide configuration center services and configuration management portal. 15. Unified management Portal
Micro service framework, a big EAR, the WAR application is open to multiple small micro service program can be run independently, usually these service programs are no longer dependent on the application server, do not rely on traditional application server, application server provides management console also don’t have to, so the runtime management of micro service needs a unified management portal to support. The unified and centralized microservice portal we have planned can support application development, business processing, application management, system monitoring and so on. The figure above is the application management page, which is to manage our traditional business system. Click on a business system, we can see what micro-services there are under the system. Each micro-service has several node instances to run again, and the status of sub-nodes of micro-services can be monitored, and micro-services can be configured, managed and monitored. 16. Distributed transaction issues
With microservices architecture, processes multiply, and the problem of distributed transaction consistency becomes more obvious. When we say transaction consistency here, we are not talking about traditional technical transactions based on database implementation. Microservices are independent and the call protocol is stateless, so the database transaction scheme is out of the question in the first place. What we need to solve is to reach the final consistent state of data after a certain period of time. To be precise, it is to adopt the traditional way of business compensation and rectification. There are three recommended transaction consistency schemes: Reliable event mode: Events are sent and received to ensure high reliability and achieve transaction consistency. Compensation mode: Confirm Cancel. If the confirmation fails, it will be cancelled in reverse order. TCC mode: Try Confirm Cancel, a special implementation of the compensation mode. This mode is usually used for transfer transactions. 17. Distributed synchronous invocation problem
Micro service architecture, compared with the traditional way of deployment, there are more distributed calls, the “how to determine the delivery service in the uncertain environment”, this sentence can be understood as simply, I rely on the reliability of the service is no guarantee that the case, how can I guarantee to be able to normal service, I rely on other services of sink? We recommend the SEDA architecture to solve this problem.
SEDA: Staged Event-driven Architecture (SEDA) is essentially a distributed event-driven architecture consisting of asynchronous simulation for synchronization, non-blocking wait, and isolation of resource allocation. 18. Continuous integration and continuous delivery design
In terms of operation and maintenance, the first thing we need to solve is continuous integration and continuous delivery. Currently, the responsibility scope of micro-service application platform is only continuous integration, which can conveniently compile programs into media packages and deployment packages with continuous integration environment. (Currently, the continuous deployment is planned to be provided by the DevOps platform, and the micro-service platform can be integrated with the DevOps platform.) Here we need to clarify a concept: media is the product of source code compilation, independent of the environment, and should be shared in multiple environments, such as JAR and Dockerfile; Configuration: indicates environment-related information. Configuration + Media = Deployment package. After obtaining the deployment package, the responsibilities of the micro-service application platform are completed, and the next step is for the operation and maintenance personnel to perform the online deployment operation. 19. Relationship between microservice platform, container cloud and DevOps
The microservice application platform itself does not rely on DevOps and container cloud, and developed deployment packages can run on physical machines, virtual machines, or containers. However, when the microservice application platform combines DevOps with the container cloud, continuous integration and delivery becomes a very simple and reliable process. With a few simple steps, an entire development, test, pre-release or production environment can be built. The complexity of the whole process is shielded by the platform, and through the integration of the three basic environments, we can make unified management, operation and delivery of decentralized microservice components easier and more convenient. Let’s review the relationship between the three basic environments. Microservice application platform is responsible for application development, operation and management; DevOps is responsible for project management, program management, CI, CD, team communication and collaboration, etc. The container cloud platform manages the infrastructure and shields the environment from complexity. The construction of these three basic environments directly reflects the level of enterprise IT capability. These three basic environments are what technicians and enterprises all want to have, which are the basis for enterprises to win competition and drive business innovation, and the only way for enterprises to accelerate digital transformation. Finally, let’s take a look at The next generation of The Platform being developed by Puyuan.
The content in the red box above is related to the microservices application platform we share today. From The perspective of The overall architecture planning of The enterprise, we aim to build a sustainable IT ecological environment for The enterprise and accelerate The digitalization of The enterprise. If you also want to get a high salary in IT industry, you can attend our training camp courses, choose the most suitable for their own courses to learn, technical masters teach, 7 months later, enter the famous enterprises to get a high salary. Our course content includes: Java engineering, high performance and distributed, high performance, easy to understand. High architecture. Performance tuning, Spring, MyBatis, Netty source analysis and big data and other knowledge points. If you want to get a high salary, want to learn, want to have a good employment prospect, want to compete with others to get an advantage, want to enter Ali interview but worry about the interview, you can come, group number is: 454377428 note: 1, have 1-5 work experience, do not know where to start in the face of the current popular technology, need to break the technical bottleneck can add. 2. I have been in the company for a long time and have been comfortable, but I hit a wall in the interview when I changed my job. Need to study in a short period of time, job-hopping can be added. 3. If you have no working experience, but have a solid foundation, and have a good command of Java working mechanism, common design ideas and common Java development framework, you can add. 4, feel very good B, general needs can be done. But the knowledge points learned are not systematic, it is difficult to continue to break through in the field of technology can be added. 5. Ali Java senior bull live explain knowledge points, share knowledge, sorting out and summarizing years of work experience, with everyone to establish their own technical system and technical knowledge in a comprehensive and scientific way! 6. No small or small white or other groups, thank you. We have the target, now it’s action! Remember: learning is always your business, and you won’t have much time if you don’t learn, but you can sometimes use what you learn to have more fun! Time is the basic component of life, but also the fundamental scale of all things exist, our time is there, our life is there! Our values will rise or fall there too! Java programmers, come on