1. Zhang Yi, the author of "Software Design Essentials and Patterns ", said in an interview with InfoQ: "One of the ways to evaluate the pros and cons of an architecture is to expand each functional and non-functional factor, and then look at how this architecture will No problem." (I agree with this statement) His point is that the architecture is designed for the future of the business, and the future is constantly evolving. The architecture should not only carry the growth of the business, but also take into account the trend of technological development.
Foreword (June 2016)
2. I think anyone who does architecture needs to adhere to the idea of "business needs determine the technological evolution route" . Those exposed status quo and problems drive the system to transform, and find an optimal cooperation model between the system and people. Match existing productivity and generative relationships. As software development guru Kent Bech said: Design is to make it easier for you to keep software changes in the long-term process.
Under the circumstance that the volume is not large, the first thing to solve is to build a set of absolutely stable platform based on modularization. When the volume gradually grows up, it will be split according to the actual needs, and the team will also change accordingly. In the next stage, the volume road is subject to the monolithic model think tank, and platform services should also be built first. After the construction is completed, it should be split according to the large granularity, and then gradually microserviced. Otherwise, it will be directly serviced or even microserviced. are very dangerous.
Microservices is a methodology that supports an application with a series of small service development. Services are independent in their own processes and interact through a lightweight communication mechanism (usually HTTP). These services are built around the business organizational structure. , fully automated, self-contained deployment. There is little to see a centralized service management infrastructure, and different services can be implemented using different programming languages and data storage technologies.
The book "Building Microservices" mentions that "microservices are a bunch of small, autonomous services that work together." The characteristics of microservices are:
1. Module as a Service
The components in microservices tend to be subdivided at the logical or physical level. This subdivision is not extreme, but a moderate choice. Usually these components can be some modules in the early stage, but when needed, such as business It can be flexibly disassembled if it needs to be split and independent, or if it needs to be expanded in terms of non-functional requirements.
2. Independence and self-government
This means that services are independently developed, tested, released, deployed, and operated independently, and a subdivision team is responsible for the entire life cycle management. This is the popular interpretation of "Conway's Law". The structure of the design results often corresponds to the communication structure in the organization." Isn't the planning of services a communication mode of multi-person and cross-team collaboration?
At the same time, the problem of affecting the whole body is removed, and a single responsibility is used to modify requirements or reconstruct a point. It is convenient to develop and build, and does not affect the function of the entire product. A bug will not crash the entire product. , distinguish between "computation-intensive" and "IO-intensive", distinguish whether it is better to use relational or NoSQL in business, distinguish the 2/8 principle (that is, 80% of frequently modified services are independent and independent), distinguish short-board functions, target bottlenecks It can do horizontal expansion, avoid resource competition, and even distinguish technology stacks and break through language restrictions. Independent services can be reused to a large extent, and services rely on lightweight interfaces instead of modules.
3. Decentralized data management
When microservices split services, they also need to separate the database, and independent services maintain independent databases, which also reduces the burden on the database. At the same time, technology selection and SLA guarantees will be separated, and the energy will be reserved for those important business databases. , and treat them in a hierarchical manner, instead of treating them equally as before. A bad SQL slow query of an unimportant logic library blocks other normal queries, which can be completely avoided.
4. Lightweight communication protocol
Traditional SOA uses heavyweight solutions such as ESB or WebService. Microservices recommend using some lighter solutions. For versatility, you can use RESTFul architecture, use HTTP channels, and support JSON serialization protocol; high performance is required Yes, you can consider using high-performance IO models, such as Epoll, Actor, etc., based on TCP channels, using protobuf serialization protocol, and maintaining long connections; to be asynchronous, you can use persistent RabbitMQ or high-performance ZeroMQ to do P2P, pub/ sub etc. And this kind of lightness also needs to be reflected in the code call. The modularization can be called directly through functions and methods. After the service can achieve non-intrusive, seamless switching, and simple configuration at the API level, these are all services. framework to support.
5. Design for Failure
Service-oriented, because the call is cross-process and distributed, the natural unreliability caused by this distributed feature needs to be relatively controllable. That is, the communication between services will not be successful to set up, and it will be handled as a failure.
In order not to affect the entire product and to isolate errors, you can consider measures such as circut break, cabin isolation mode, current limiting, fallback, and finally idempotency (will retrying affect the business?) .
6. Infrastructure Delivery Facility Automation
This feature is the biggest highlight of the entire microservice, including continuous integration CI, continuous delivery CD and Pass platform combination. In the context of subdivision, microservices increase the complexity of project results and physical results, which requires a major change in basic delivery, and automated deployment is a must.
Disadvantages of Microservices:
1. Performance and delay problems caused by distributed calls. (Actions that can be taken include moderate granularity, batching, high-performance RPC, asynchronous communication, etc.)
2. The reliability is not guaranteed. (designed to fail)
3. Data consistency is difficult to guarantee. (Problems involved in distributed design itself, eventual consistency, strong consistency, etc.)
4. The overall complexity is improved. There are many services, many dependencies, and many calls, how to manage contracts, how to monitor them, how to determine which point has a problem on the call chain, SLA guarantees, performance, error rates, alarms, integration testing, and deployment of services.
Architectures are just standards, skeletons, and the discussion of microservices shouldn't let us forget the more important issues, the important factors that drive the success and failure of software projects. Soft factors, such as the quality of the people on the team and how they collaborate and communicate with each other, can have a big impact on whether or not to use microservices. On a purely technical level, the focus should be on clean code, well-developed tests, and continuous attention to architectural evolution. This is the fundamental responsibility of a software engineer.
"Talking about the microservice transformation of back-end business systems" (June 2016)
3. The traditional enterprise-level application is a single application , which is generally a layered structure, such as the presentation layer, the application layer, the domain layer, and the data layer. This is mainly the idea of horizontal segmentation.
With the development of Internet applications, especially large-scale e-commerce systems, the business is very complex. For this kind of giant system, the first thing to focus on is how to divide the subsystems according to the business, then how to cooperate between the subsystems, and finally the internal implementation of the subsystems. SOA design can effectively support the first two steps. In the SOA system, each subsystem is an independent service, and the service interface reflects the cooperation relationship between the subsystems. As for the interior of the subsystem, it is directly handled as a black box.
Therefore, for complex systems, firstly, SOA is used to vertically cut the sub-system, and then the hierarchical design is used to horizontally divide the large single subsystem, and service-oriented pushes the traditional hierarchical design one step further.
Of course, SOA itself is also developing continuously. The initial cross-enterprise Web Service interaction can be considered as the 1.0 era, supporting lightweight access between internal systems of the enterprise and supporting service governance, which can be considered as the 2.0 era; further layering of services and microservices can be considered as the era 3.0 era.
"Business is changing, technology is changing, and architecture is also changing. What changes is the form, but the essence is the same. The architecture is for the system to be more orderly, the system is for the business to be faster, and the business is for a better life."
"Preface - Architecture Development Trends and Status Quo" (March 2016)
Four,
"KumuluzEE is the first microservices framework to use standard Java APIs. The point of a microservices architecture is to develop applications into services and deploy those services individually; without a framework that provides automated deployment and configuration, it is impossible to use JavaEE to achieve true of the microservices architecture".