[Spring Cloud 5] The relationship between SOA architecture and microservice architecture

1. System architecture evolution

With the development of the Internet, the scale of website applications continues to expand. The surge in demand brings technical pressure. Therefore, the system architecture is constantly evolving, upgrading, and iterating. From a single application, to vertical splitting, to distributed services, to SOA, and now the hot microservice architecture, as well as the surging Service Mesh led by Google. Should we take a micro-service boat to sail far away, or should we just pass by?

In fact, life is not only about the present, but also poetry and the distance. So today we will review the history and take a look at the evolution of the system architecture; grasp the present and learn the most popular technical architecture; look forward to the future and strive to become an excellent Java engineer.

1. Centralized architecture

When the website traffic is very small, only one application is needed and all functions are deployed together to reduce deployment nodes and costs. At this time, the data access framework (ORM) used to simplify the workload of adding, deleting, modifying and checking is the key to project development.

As shown in the figure, this system adopts a three-tier architecture, a presentation layer, a business logic layer, and a data access layer. Although the three-tier architecture solves the problem of complex calls between codes and unclear code responsibilities in applications. But he only divides the application into three layers logically, not physical layering. After compilation, packaging, and deployment, it will eventually run in the same process on the same machine. This kind of function is centralized and the code is centralized. , A release package, an application that runs in the same process after deployment, we usually call it a monolithic application.

What are the advantages of monolithic applications?

• Easy to develop
• Easy to test
• Easy to deploy

Existing problems:

• Code coupling, difficult to develop and maintain
• Can't be optimized for different modules
• Cannot scale horizontally
• Low single-point fault tolerance and poor concurrency
• Technology selection is costly-monolithic applications make it extremely difficult to adopt new frameworks and languages. For example, if you have two million lines of code using the XYZ framework, if you want to rewrite the code using the ABC framework, both time and cost will be very high. Even if the new framework is better, this will become an obstacle to the use of new technologies.
• Long delivery cycle-Generally, the release train method is adopted, and all the functions used need to be ready before release.

2. Vertical split

When the number of visits gradually increases, a single application cannot meet the demand. At this time, in order to cope with higher concurrency and business requirements, we split the system according to business functions:

advantage:

• System splitting realizes traffic sharing and solves concurrency problems
• Can be optimized for different modules
• Convenient horizontal expansion, load balancing, and improved fault tolerance

Disadvantages:

• The systems are independent of each other, there will be a lot of repeated development work, which will affect the development efficiency

3. Distributed service

When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, gradually forming a stable service center, so that front-end applications can respond more quickly to changing market demands. At this time, distributed calls for improving business reuse and integration are the key.

advantage:

• The basic services are extracted and the systems call each other, which improves code reuse and development efficiency

Disadvantages:

• The degree of coupling between systems becomes higher, the calling relationship is intricate and difficult to maintain

4. Service governance SOA

Microservices and SOA

SOA

• The earliest appearance of SOA is to solve the integration problem between different systems of the enterprise, and propose service reuse and message bus.
• There are a lot of orchestration in SOA, usually through the message bus to carry business logic, and build heavyweight centralized middleware.
• A big problem with SOA is the bus . According to this idea, these systems will always be centralized in a certain link, so the decentralization is not thorough.

Microservice

• Goal: Help companies respond to changes faster
• Purpose: Decentralization

When more and more services are available, problems such as capacity assessment and the waste of small service resources gradually appear. At this time, a dispatch center needs to be added to manage cluster capacity in real time based on access pressure to improve cluster utilization. At this time, the resource scheduling and governance center (SOA) used to improve machine utilization is the key

What happened before?

• More and more services need to manage the address of each service
• The call relationship is intricate and difficult to sort out the dependency relationship
• Too many services, the service status is difficult to manage, and cannot be dynamically managed according to the service situation

What does service governance do?

• Service registration center, realizing automatic service registration and discovery, without the need to manually record the service address
• Automatic service subscription, automatic push of service list, transparent service call, no need to care about dependencies
• Dynamic monitoring service status monitoring report, human control service status

Disadvantages:

• There will be dependencies between services, once a link goes wrong, it will have a greater impact
• The service relationship is complex, operation and maintenance, test deployment is difficult, and it does not conform to the DevOps idea

Two, microservices

The SOA mentioned above, the English translation is service-oriented. Microservices, which seem to be services, are all splitting the system. So the two are very easy to confuse, but in fact there are some differences:

1. Features of microservices

• Single responsibility: each service in the microservice corresponds to a unique business capability, achieving a single responsibility
• Micro: The granularity of service splitting of microservices is very small, for example, a user management can be used as a service. Each service is small, but "complete with all internal organs".
• Service-oriented: Service-oriented means that each service must expose the service interface API. It does not care about the technical implementation of the service, it has nothing to do with the platform and language, and it does not limit what technology to use, as long as the interface of Rest is provided.
• Autonomy: Autonomy means that services are independent of each other and do not interfere with each other
  • Team independence: Each service is an independent development team, and the number of people cannot be too large.
  • Technology independence: Because it is service-oriented and provides Rest interface, no one else interferes with what technology is used
  • Front-end and back-end separation: use front-end and back-end development to provide a unified Rest interface, and the back-end does not need to develop different interfaces for PC and mobile segments
  • Database separation: each service uses its own data source
  • The deployment is independent. Although there are calls between services, the restart of the service does not affect other services. Conducive to continuous integration and continuous delivery. Each service is an independent component, reusable, replaceable, reducing coupling, and easy to maintain

Microservice structure diagram:

2. Design principles of microservices

3. High cohesion and low coupling

• Closely related things should be put together. Each service is an encapsulation of a single responsibility business capability, focusing on doing one thing well (only one reason to change it at a time). As shown in the figure below: There are four services a, b, c, and d, but each service has a different responsibilities. A may be doing b, b is doing c, and c is doing a at the same time. After adjusting, putting related things together can reduce unnecessary services.
• Lightweight communication method
  • Synchronous RESTful (GET/PUT/POST...), based on http, can make the communication between services standardized and stateless. Regarding the maturity of the RESTful API, please refer toRichardson为REST定义的成熟度模型
  • Asynchronous (message queue/publish and subscribe)
• Avoid sharing databases between services

4. High degree of autonomy

• Independent deployment, operation and expansion
  • Each service can be deployed independently and run in a process
  • This mode of operation and deployment can give the system a flexible code organization and release rhythm, making it possible to quickly deliver and respond to changes.
• Independent development and evolution
  • The technology selection is flexible and not restricted by the legacy system technology stack.
  • The right business problem can choose the right technology stack, which can evolve independently
  • Use language-independent APIs for integration between services
• Independent team and autonomy
  • The team is responsible for the entire life cycle of the service, working in an independent context, who develops it and who maintains it.

5. Focus on business

• Each service represents a specific business logic
• Clear boundary context
• Organize the team around the business
• Can quickly respond to business changes
• Isolate implementation details so that business areas can be reused

Flexible design

• Design a fault-tolerant system
  • Embrace failure, design for known errors
  • The dependent service hangs
  • Network connection problem
• Design a system with self-protection capabilities
  • Service isolation
  • Service degradation
  • Limit the use of resources
  • Prevent cascading errors

6、Netfilix

Netfilix provides a better solution. Specific countermeasures include: network timeout/limiting the number of requests/breaker mode/providing rollback, etc.

Hystrix records calls that exceed preset limits. It implements the circuit break mode, thereby avoiding endless waiting for unresponsive services. If the error rate of a service exceeds the preset value, Hystrix will interrupt the service, and all requests for the service will immediately become invalid within a period of time. Hystrix can define a fallback operation for request failure, such as reading the cache or returning to the default value.

7. Logs and monitoring

When the product environment goes wrong, it is necessary to quickly locate the problem and detect possible accidents and failures. Logging and monitoring are the best choice for rapid positioning and prevention, and they are even more important in the microservice architecture.

• Highly observable, we need to have a holistic view of what is happening.
• Aggregate your logs, aggregate your data, so that when you encounter problems, you can analyze the reasons in depth.
• When you need to reproduce an annoying problem, or just look at how your system interacts in a production environment, it 关联标识can help you track calls between systems.

Monitoring mainly includes service availability status, request flow, call chain, error count, structured log, service dependency visualization, etc., so that problems can be fixed in time, system load can be adjusted in real time, service degradation, overload protection, etc., if necessary, So that the system and the environment provide efficient and high-quality services.

For example, commercial solutions splunk，sumologicand open source products ELK can be used for log collection, aggregation, display, and provide search functions, based on certain conditions, trigger email warnings.

Spring boot adminIt can also be used to monitor service availability.  hystrixIn addition to providing a fuse mechanism, it also collects some basic information about the request (such as request response time, access calculation, error statistics, etc.), and provides a ready-made dashboard to visualize the information.

Regarding performance monitoring and call chain tracing, consider using dynatrace and zipkin/Sleuth

8. Automation

Under the microservice architecture, the following challenges are faced:

• Distributed Systems
• Multi-service, multi-instance
• Manual testing, deployment, and release are too time-consuming
• The feedback cycle is too long

Traditional manual operation and maintenance methods will inevitably be eliminated. The implementation of microservices has certain prerequisites: that is automation. When services become large-scale, more 自动化and more 标准化methods are needed to improve efficiency and reduce costs.

• Automated testing is indispensable because it is a more complicated process to ensure that a large number of our services work properly compared to a monolithic system.
• Invoke a unified command line to deploy the system to each environment in the same way.
• Consider using environment definitions to help you clarify the differences between different environments, but at the same time maintain the ability to deploy in a uniform way.
• Consider creating custom images to speed up deployment and embrace the practice of fully automated creation of immutable servers.

自动化一切可以自动化的, To reduce the difficulty of deployment and release, such as: in continuous integration and continuous delivery, automatic compilation, testing, security scanning, packaging, integration testing, deployment, as more and more services, in the release process, the need for further automation blue Green deployment (to achieve a smooth transition from the old version to the new version) can also use the practice of pipeline as code, and use code to describe your pipeline. There are many options for deployment, you can use virtual machines, container docker, or popular serverless architecture lambda (AWS Lambda also has some obvious limitations. It is not suitable for deploying long-running services, the request needs to be completed within 300 seconds , Of course you can delay the time by hacking).

Then, you can use infrastructure and code practices, such as Amazon's cloudformation, and terrformuse code to describe infrastructure such as computing and networks, which can quickly provide a new service, build the environment it needs, and maintain each 环境的一致性.

9. What are the advantages of microservices?

1. Each microservice is very small, so that it can focus on a specific business function or business requirement. The microservice architecture pattern provides a modular solution for functions that are difficult to implement using a single coding method. As a result, a single service is easy to develop, understand, and maintain.

2. Microservices can be independently developed by a small team, which is composed of 2 to 5 developers.

3. Microservices are loosely coupled and are functionally meaningful services that are independent in either the development or deployment phases, which can speed up deployment. The UI team can use AB testing to quickly deploy changes. The microservice architecture model makes continuous deployment possible

4. Microservices can be developed in different languages.

5. Microservices are easy to be understood, modified and maintained by a developer, so that small teams can pay more attention to their work results. No need to cooperate to realize value.

6. Microservices allow you to take advantage of the latest technologies.

7. Microservices are just business logic code and will not be mixed with HTML, CSS or other interface components.

10. Disadvantages of microservice architecture?

1. Microservice architecture may bring too many operations (service split)

2. DevOps skills are required.

3. Probably double the effort.

4. Distributed systems can be complex and difficult to manage. Developers need to choose between RPC or messaging and complete the inter-process communication mechanism. What's more, they must write code to deal with local failures such as slow or unavailability in message delivery. Of course, this is not a difficult task, but compared to monolithic applications through language-level methods or process calls, this technology under microservices is more complicated.

5. It is difficult to track the distribution and deployment.

6. When the number of services increases, management complexity increases

7. Partitioned database architecture. It is very common to update news to multiple business sub-subjects at the same time in commercial transactions. This kind of transaction is easy for a single application because there is only one database. In microservice architecture applications, different databases used by different services need to be updated. Using distributed transactions is not necessarily a good choice, not only because of the CAP theory, but also because today's highly scalable NoSQL databases and messaging middleware do not support this demand. In the end, you have to use an eventually consistent method, which poses higher requirements and challenges to developers.

Three, know RPC

RPC, that is, Remote Procedure Call (remote procedure call), is a computer communication protocol. This protocol allows programs running on one computer to call subroutines of another computer without the programmer needing to program this interaction. To put it simply, computer A provides a service, and computer B can call the service of computer A just like calling a local service.

Through the above concepts, we can know that the realization of RPC mainly does two things:

• Realize the service of remotely calling other computers
  • To realize remote calls, data must be transmitted through the network. Program A provides services, program B passes the request parameters to program A through the network, A gets the result after local execution, and then returns the result to program B. There are two points to be concerned about here:
    • 1) Which network communication protocol is used?
      • The more popular RPC frameworks now use TCP as the underlying transmission protocol
    • 2) What is the format of data transmission?
      • For two programs to communicate, the data transmission format must be agreed upon. It's like two people chatting, they have to use the same language, otherwise they can't communicate. Therefore, we must define the format of the request and response. In addition, data needs to be serialized during network transmission, so a unified serialization method needs to be agreed upon.
• Call remote service like local service 
  • If it is only a remote call, it is not considered an RPC, because RPC emphasizes a procedure call. The process of the call should be transparent to the user. The user should not care about the details of the call, and can call the remote service like a local service. So RPC must encapsulate the calling process.

RPC call flow chart:

 

Previous: [Spring Cloud 4] Building a high-performance large-scale distributed website

Next article:  SpringCloud learning general outline