The series of articles on microservices architecture will describe the definition, characteristics, application scenarios, evolution of enterprise integration architecture, microservices transformation ideas and technical decision-making considerations in several articles, the following uses IBM technology as an example to describe how to transform the microservice architecture.
"Microservice" architecture is a very popular concept in the software application field recently. Let's take a look at some problems faced by traditional IT architecture:
The use of traditional monolithic architecture (monolithic architecture) application development systems, such as CRM, ERP and other large applications, as new demands continue to increase, it is increasingly difficult for enterprises to update and repair large-scale integrated applications;
With the development of mobile Internet, enterprises are forced to migrate their applications to the modern UI interface architecture to be compatible with mobile devices, which requires enterprises to be able to quickly publish application functions;
Many enterprises have limited return in their SOA investments. SOA can reuse capabilities through standardized service interfaces. However, the demand for rapid changes is limited by the integral application, and sometimes it is insufficient;
With the increasing popularity of application cloudification, applications born on the cloud have different technical genes and development and o & M modes from traditional it.
In addition, from the technical perspective, a large number of open source and lightweight technologies of cloud computing and Internet companies keep emerging and gradually mature:
The Internet/Intranet/network is more mature;
The emergence of lightweight runtime technologies (such as node. js and was liberty );
New methods and tools (agile, devops, TDD, CI, XP, puppet, Chef ...);
New lightweight protocol (restful API interface, lightweight message mechanism );
Simplified infrastructure: hypervisors, e.g. docker, infrastructure as a service (IAAS), and workload Virtualization (kubernetes, spark ...) And so on;
Service platformization (PAAs): The cloud service platform provides various on-demand services such as automatic scaling, workload management, SLA management, message mechanism, cache, and build management;
New alternative data persistence models: nosql, mapreduce, base, cqrs, etc;
Standardized Code Management: such as GitHub.
All of these gave birth to the emergence of a new architecture design style-microservice architecture.
Microservices are an architectural style. A large complex software application consists of one or more microservices. Each microservice in the system can be deployed independently, and each microservice is loosely coupled. Each microservice only focuses on completing a task and completing it well. In all circumstances, each task represents a small business capability.
The concept of microservices is derived from an article, http://martinfowler.com/articles/microservices.html, written by Martin Fowler in March 2014 ).
Although the architecture style "microservices" is not exactly defined, it has some common features, such as organizing services, automatic deployment, smart endpoints, and "de-Centralization" Control of language and data around business capabilities.
The Thinking of microservice architecture comes from the comparison with the overall application.
The encapsulation of application components is the main difference between the overall architecture and the microservice architecture. The microservice architecture puts the related business logic and data together to form an independent boundary, it aims to deliver and launch the market faster without affecting other application components (microservices.
According to the analysis of martinfowler, microservice architecture has the following common features, but not all microservice architecture applications must have all these features:
Componentizationvia services: components in a microservice architecture are defined as software units that can be independently replaced and upgraded, in the application architecture design, components are designed by splitting the entire application into microservices that can be independently deployed and upgraded.
Organizedaround business capabilities: the microservice architecture adopts a service organization strategy based on business capabilities. Therefore, the organizational structure of the microservice team must be cross-functional (for example: applications, databases, and devops development and o & M Integration Teams with strong mix. These teams are usually not too large (for example, Amazon's "Two pizzateam"-no more than 12 people ).
Product rather than project model (productsnot projects): a traditional application model is a team that develops complete applications in the project model. After the development is complete, the Team is responsible for maintenance; the microservice architecture advocates that a team should be responsible for a complete "microservice" Life Cycle like development products, and advocate an integrated development, O & M approach of "who develops and who operates.
Smartendpoints and dumb Pipes, communication mechanisms or components should be as simple and loosely coupled as possible. Restful HTTP protocol and lightweight asynchronous mechanism that only provides message routing functions are the most common communication mechanism in microservice architecture.
"Decentralized" Governance (decentralizedgovernance): monolithic applications tend to adopt a single technical platform, while microservices architecture encourages the use of appropriate tools to complete their respective tasks, you can choose the best tool for each microservice (for example, different programming languages ). Microservice technical standards tend to look for technologies that other developers have successfully verified to solve similar problems.
"Decentralized" Data Management (decentralizeddata management): The microservice architecture advocates the use of the polyglotpersistence method to allow each microservice to manage its own database, different microservices are allowed to adopt different Data Persistence Technologies.
Infrastructure automation: cloud-based and automated deployment technologies greatly reduce the difficulty of microservice construction, deployment, and O & M, through continuous application integration and continuous delivery, you can accelerate the launch of the market.
Designfor failure: one consequence of a microservice architecture is the failure tolerance mechanism of each service. Therefore, microservice attaches great importance to the establishment of real-time monitoring and log mechanisms for architecture and business-related indicators.
Evolutionarydesign: microservice applications focus more on rapid updates, so the system plans will change and evolve over time. Microservice design is affected by factors such as the lifecycle of business functions. If an application is an integral application, but gradually evolves towards the microapplication architecture, the integral application is still the core, but the new functions will be built using the API provided by the application. Another example is the basic principle of alternative modular design in a microservice application. After implementation, it is found that a single microservice must be updated at the same time, this probably means that it should be merged into a microservice.
Clarification on some comparative concepts:
Comparison within the same category makes sense:
Microservice architecture vs. SOA-both of them are in the architectural style category, but their areas of interest and scope are different. SOA focuses more on enterprise scale, while microservice architecture focuses more on application scale.
Microservices vs. service components-both describe the specific implementation of business functions. The difference lies in different granularities and differences in manageability and flexibility.
Inappropriate comparison of concept Obfuscation
Microservice vs. SOA-inappropriate comparison. Microservices are components, while SOA is an architectural design style. Therefore, we should compare the microservice architecture with SOA.
Microservice vs. API-inappropriate comparison. APIs are interfaces and are a mechanism for exposing business functions. Microservices architecture is a component architecture used to implement business functions. Therefore, it is meaningless to directly compare them.
Microservice vs. Service-inappropriate comparison. "Service" has different meanings in different scenarios. The context that needs to be further clarified indicates service implementation, service exposure, service definition, and others? This is also true for microservices. A specific context is required to determine whether the comparison is meaningful.
The Application of flight reservation is divided into seven microservices: booking flights, querying schedules, calculating fares, assigning seats, managing rewards, updating customers, and adjusting inventory.
Record Systems (system of record) will benefit the most from microservice methods. For example, large applications can be divided into several microservices based on relatively independent business functions.
A balanced system (System of engagement) will also benefit from microservice methods. For example, channel applications can apply the "backend service frontend" mode.
System of insight may not benefit much from microservices. Other architecture modes, such as pipelines and filtering modes, may be more suitable for analyticdb systems.
Each service is relatively simple and focuses only on one business function.
The microservice architecture is loosely coupled to provide higher flexibility.
Microservices can be developed through the best and most appropriate programming languages and tools to solve targeted problems.
Each microservice can be independently developed by different teams, without affecting each other and accelerating the launch of the market.
The microservice architecture is a huge driving force behind CD, allowing frequent releases of different services while maintaining availability and stability for other parts of the system.
Some Ideas about microservices are good in practice, but they also present complexity in the overall implementation.
O & M overhead and cost increase: the overall application may only need to be deployed to a cluster in a small application service area, while the microservice architecture may need to build, test, deploy, and run dozens of independent services, it may need to support multiple languages and environments. As a result, if an integrated system is composed of 20 microservices, it may take 40 ~ 60 processes.
Must have solid devops development and o & M integration skills: developers need to be familiar with the O & M and production environments, and developers also need to master the necessary data storage technologies such as nosql, the scarcity of personnel with strong devops skills brings challenges to talent recruitment.
Implicit interface and interface matching: a new interface is generated after the system is divided into multiple cooperative components, which means that simple cross-changes may need to change many components and need to be released together. In the actual environment, a new product release may be forced to publish a large number of services at the same time. Due to the increasing number of integration points, the microservice architecture has a higher risk of publishing.
Code duplication: some underlying functions need to be used by multiple services. To avoid "synchronous coupling into the system", you sometimes need to add some code to different services, this will lead to code duplication.
Complexity of Distributed Systems: as a distributed system, microservices introduce complexity and other issues, for example, network latency, fault tolerance, message serialization, unreliable network, asynchronous mechanism, version, and differentiated workload, developers need to consider the above distributed system issues.
Asynchronous mechanism: microservices often use asynchronous programming, messaging, and parallel mechanisms. If an application has cross-microservice transaction processing, its implementation mechanism will become more complicated.
Testability challenges: interactions between services in a dynamic environment can produce very subtle behaviors, making it difficult to visualize and perform comprehensive tests. Classic microservices often do not pay much attention to testing. More importantly, they discover exceptions in the production environment through monitoring, and then quickly roll back or take other necessary actions. However, you need to pay special attention to the scenarios that are especially concerned about risk avoidance and supervision or production environment errors will have a significant impact.
In the right project, the right team, using the microservice architecture will benefit more than the cost.
Microservice architecture has a lot of attractions, but before embracing microservices, you also need to recognize the challenges it brings.
Avoid "microservices" for "microservices ".
Microservice architecture introduction strategy-for traditional enterprises, some appropriate microservice architecture principles can be introduced to transform existing systems or create microservice applications, gradually explore and accumulate microservice architecture experience, rather than fully implement the microservice architecture.
Reposted from: 76408158
Microservice architecture (I): What is microservices?