Evolution of system architecture: differences and connections between SOA and microservice architecture

Click on the official account , Practical technical articles Know in time

source ：glory.blog.csdn.net/article/details/97297895

1. System architecture evolution

With the development of the Internet , The scale of web applications continues to grow . The surge in demand , It's the technical pressure . The system architecture is also evolving 、 upgrade 、 iteration . From a single application , To split vertically , To distributed services , To SOA, And now the hot microservice Architecture , And in Google Led by the surging Service Mesh. We should take the micro service ship to the distance , It's better to live in a corner ？

In fact, life is more than just living in front of you , And poetry and distance . So let's review history today , Take a look at the evolution of system architecture ; Grasp now, , Learn the hottest technology architecture now ; Looking forward to the future , Strive to be an excellent Java The engineer .

1.1. Centralized architecture

When website traffic is low , Just one app , Deploy all functions together , To reduce deployment nodes and costs . here , Data access framework to simplify the work of adding, deleting, modifying and querying (ORM) Is the key to project development .

As shown in the figure , The system adopts a three-tier architecture , The presentation layer , Business logic layer , Data access layer , Although the three-tier architecture solves the complex problem of calling between codes in applications , The problem of unclear code responsibilities . But he only divides the application into three layers in logic , It's not a physical layering , Compile , pack , After deployment , Finally, it runs in the same process of the same machine , This centralization of functions , Code centralization , A release package , Applications running in the same process after deployment , We usually call it monomer architecture application .

Advantages of monomer application ？

• Easy to develop

• Easy to test

• Easy to deploy

The problem is ：

• Code coupling , It is difficult to develop and maintain

• It is not possible to optimize for different modules

• Can't expand horizontally

• Low single point fault tolerance , Poor concurrency

• The cost of technology selection is high - Monolithic applications make it extremely difficult to adopt new frameworks and languages . for instance , You have two million lines to use XYZ Code for the framework , If you want to use ABC Framework rewrite code , Both time and cost will be very high , Even if the new framework is better , This has become an obstacle to the use of new technologies .

• Long lead time - It is generally used release train The way , You need to have all the functions ready to release .

1.2. Split Vertically

When the number of visits increases gradually , A single application can't meet the demand , In order to meet the higher concurrency and business requirements , We split the system according to the business function ：

advantage ：

• System splitting realizes traffic sharing , Solved the concurrency problem

• Can be optimized for different modules

• Convenient horizontal expansion , Load balancing , Improved fault tolerance

shortcoming ：

• The systems are independent of each other , There will be a lot of repetitive development work , Impact on development efficiency

1.3. Distributed services

As more and more vertical applications , Interaction between applications is inevitable , Extract core business , As an independent service , Gradually form a stable service center , Enable front-end applications to respond more quickly to changing market demands . here , Distributed invocation for improving business reuse and integration is the key .

advantage ：

• The basic services are extracted , Inter system calls , Improved code reuse and development efficiency

shortcoming ：

• The coupling degree between systems becomes higher , The call relationship is complex , Difficult to maintain

1.4. Service governance （SOA）

Micro service and SOA

SOA

• SOA It first appeared to solve the problem of integration between different systems of enterprises , Propose service reuse and message bus .

• SOA There are a lot of choreography , Business logic is usually carried through the message bus , And build a heavyweight centralized middleware .

• SOA A big problem is the bus , According to this idea , These systems will always be centralized in some link , So decentralization is not complete .

Microservices

• The goal is ： Help enterprises respond to changes faster

• Purpose ： De centralization

When the service is more and more , Capacity assessment , Problems such as waste of small service resources are gradually emerging , At this time, it is necessary to add a dispatching center to manage the cluster capacity in real time based on the access pressure , Improve cluster utilization . here , Resource scheduling and Governance Center for improving machine utilization (SOA) Is the key

What happened before ？

• More and more services , Need to manage the address of each service

• The call relationship is complex , It's hard to make sense of dependency

• Too much service , Service state is difficult to manage , Can't dynamically manage... Based on service conditions

What should service governance do ？

• Service registry , Realize automatic service registration and discovery , There is no need to record the service address

• Service auto subscription , Service list auto push , Service call transparency , Don't care about dependencies

• Dynamic monitoring service status monitoring report , Human control of service status

shortcoming ：

• There will be dependencies between services , Once a link goes wrong, it will have a big impact

• The service relationship is complex , Operation and maintenance 、 Test deployment is difficult , Do not conform to the DevOps thought

1.5. Microservices

As mentioned above SOA, The English translation is service-oriented . Microservices , It seems to be a service , It's all about splitting the system . So it's very easy to confuse the two , But there are some differences ：

Features of microservices ：

• Single responsibility ： Each service in the microservice corresponds to a unique business capability , Single responsibility

• tiny ： The service splitting granularity of microservices is very small , For example, a user management can be used as a service . Every service is small , but “ Five zang organs ”.

• Service oriented ： Service orientation means that every service should expose its service interface to the outside world API. Don't care about the technical implementation of services , It has nothing to do with platform and language , It's not limited to technology , Just provide Rest The interface of .

• autonomous ： Autonomy means that services are independent of each other , Mutual interference

  • Team independence ： Each service is an independent development team , There can't be too many people .

  • Technology independence ： Because it's service orientation , Provide Rest Interface , There is no interference in the use of any technology

  • Fore and aft end separation ： Adopt front and rear end separation development , Provide unity Rest Interface , The back end doesn't have to be PC、 Mobile segments develop different interfaces

  • Database separation ： Each service uses its own data source

  • Deploy independent , Although there are calls between services , But to ensure that service restart does not affect other services . For continuous integration and continuous delivery . Each service is a separate component , Reusable , alternative , To reduce the coupling , Easy maintenance

Microservice structure chart ：

The design principles of microservices

High cohesion and low coupling

• Closely related things should be put together , Each service is an encapsulation of business capabilities for a single responsibility , Focus on doing one thing well （ There's only one reason to change it at a time ). Here's the picture ： There are four services a,b,c,d, But each service responsibility is not single ,a May be doing b Things about ,b I'm doing it again c Things about ,c And at the same time doing a Things about , By readjusting , After putting the relevant things together , It can reduce unnecessary services .

• Lightweight communication

  • Sync RESTful（GET/PUT/POST…）, be based on http, It can make the communication between services standardized and stateless , About RESTful API The maturity of , Can refer to Richardson by REST Defined maturity model

  • asynchronous （ Message queue / Publish subscribe ）

• Avoid sharing databases between services

Highly autonomous

• Separate deployment runs and extensions

  • Each service can be deployed independently and run within a process

  • This way of running and deploying gives the system a flexible code organization and delivery rhythm , Enables rapid delivery and response to change .

• Independent development and evolution

  • Flexible technology selection , Not constrained by the legacy system technology stack .

  • For the right business problem, you can choose the right technology stack , Can evolve independently

  • Service to service to take between language - independent API To integrate

• Independent team and autonomy

  • The team is responsible for the entire lifecycle of the service , Work in a separate context , Who developed , Who maintains .

Focus on business

• Each service represents a specific business logic

• There is an obvious boundary context

• Organize the team around the business

• It can quickly respond to business changes

• Isolate implementation details , Make the business domain reusable

Elastic design

• Design fault-tolerant systems

  • Embrace failure , Designed for known errors

  • Dependent services hang up

  • Network connection problem

• Design a system with self-protection ability

  • Service isolation

  • service degradation

  • Limit the use of resources

  • Prevent cascading errors

Netfilix Provides a better solution , Specific countermeasures include ： Network timeout / Limit the number of requests / Breaker mode / Provide rollback, etc .

Hystrix Record calls that exceed the preset limit . It has achieved circuit break Pattern , This avoids endless waiting for unresponsive Services . If the error rate of a service exceeds the preset value ,Hystrix The service will be interrupted , And in a period of time, all requests for the service will immediately expire .Hystrix You can define a for a request failure fallback operation , For example, read the cache or return the default value .

Log and monitor

When the product environment goes wrong , Need to quickly locate the problem , Detect possible accidents and faults . Logging and monitoring are the best choice for rapid positioning and Prevention , It is even more important in microservice Architecture .

• The height is observable , We need a holistic view of what is happening .

• Aggregate your logs , Aggregate your data , So when you have a problem , We can analyze the reasons in depth .

• When it comes to reproducing annoying problems , Or just look at how your system interacts in the production environment , Association identifiers can help you track calls between systems .

Monitoring mainly includes service availability status 、 Request traffic 、 Call chain 、 Error count , Structured logs 、 Service dependency visualization, etc , In order to find problems and repair them in time , Adjust the system load in real time , Service degradation if necessary , Overload protection and so on , So that the system and environment can provide efficient and high-quality services .

For example, business solutions splunk,sumologic, And open source products ELK They can all be used for log collection , polymerization , show , And provide search function , Based on certain conditions , Trigger email warning .

Spring boot admin It can also be used to monitor service availability , hystrix In addition to providing fuse mechanism , It also collects some basic information about the request （ Such as request response time , Access Computing , Error statistics, etc ）, And provide ready-made dashboard Visualize information .

About performance monitoring and call chain tracing , Consider using dynatrace and zipkin/Sleuth

automation

In the microservices architecture , The challenges are as follows ：

• Distributed systems

• Multi service , Multiple instances

• Manual testing , Deploy , Publishing takes too much time

• Feedback cycle is too long

The traditional manual operation and maintenance mode must be eliminated , There are certain preconditions for the implementation of microservices ： That's automation , When services are scaled up, more automated and standardized means are needed to improve efficiency and reduce costs .

• Automated testing is essential , Because comparing single block systems , Ensuring that a large number of our services work properly is a more complex process .

• Call a unified command line , Deploy the system to each environment in the same way .

• Consider using an environment definition to help you clarify the differences between different environments , But while maintaining the ability to deploy in a unified way .

• Consider creating custom images to speed deployment , And embrace the practice of fully automated creation of immutable servers .

Automation everything that can be automated , Reduce the difficulty of deployment and release , such as ： In continuous integration and continuous delivery , Automated compilation , test , Security scanning , pack , Integration testing , Deploy , With more and more services , In the process of release , Need to further automate blue-green deployment （ Achieve a smooth transition from the old version to the new version ） You can also use pipeline as code Practice , Describe your pipeline in code .

There are many options for deployment , You can use virtual machines , Containers docker, Or the popular no service architecture lambda（AWS Lambda There are also some obvious limitations . It is not suitable for deploying long-running Services , Request needs to be in 300 seconds , Of course you can hack The way to delay time ).

then , You can use infrastructure and code practices , Like Amazon's cloudformation, also terrform, Use code to describe infrastructure such as computing and networks , Can quickly provide a new service , The environment it needs , Maintain the consistency of all environments .

Conway's law

The architecture of a system , It reflects the communication structure of the organization

This requires us to align the right to use the service with the team , When the two are inconsistent , We'll find a lot of friction points .

The final summary ： The goal of microservices is to provide responsiveness , It is built around business capabilities , Decentralizing everything is the highest purpose of microservices ,

Advantages of microservices ？

1. Each microservice is small , This focuses on a specific business function or business requirement . The microservice architecture mode provides a modular solution for functions that are difficult to be implemented by single coding , thus , Individual services are easy to develop 、 Understanding and maintenance .

2. Microservices can be developed individually by small teams , This small group is 2 To 5 The group of developers .

3. Microservices are loosely coupled , It's a functional service , Both in the development and deployment phases are independent , Can speed up deployment .UI Teams can adopt AB test , Rapid deployment changes . Microservice architecture pattern makes continuous deployment possible

4. Microservices can be developed in different languages .

5. Microservices are easy for a developer to understand , Modification and maintenance , This allows small teams to focus more on their work . You don't have to collaborate to be valuable .

6. Microservices allow you to leverage the latest convergence technologies .

7. Microservices are just the code for the business logic , Don't and HTML,CSS Or some other interface component mix .

Disadvantages of microservices architecture ？

1. Microservice architecture can lead to too many operations （ Service split ）

2. need DevOps skill (http://en.wikipedia.org/wiki/DevOps).

3. Maybe double the effort .

4. Distributed systems can be complex and difficult to manage . Developers need to be in RPC Or choose and complete the interprocess communication mechanism between message passing . More than , They have to write code to deal with local failures such as slow or unavailable messaging . Of course, it's not that hard , But compared with the monomer application, it can be called by language level methods or processes , This technology is more complex under microservices .

5. Distribution deployment tracing is difficult .

6. As the number of services increases , Increased management complexity

7. Partitioned database schema . In business transactions, it is common to update messages to multiple business sub entities at the same time . This kind of transaction is easy for a single application , Because there's only one database . In the application of microservice Architecture , Need to update different databases used by different services . Using distributed transactions is not necessarily a good choice , Not just because CAP theory , And because of today's highly scalable NoSQL Database and messaging middleware do not support this requirement . Eventually you have to use a final consistent approach , So it puts forward higher requirements and challenges for developers .

1.6. Microservices and SOA Differential connection

1.SOA（Service Oriented Architecture）“ Service Oriented Architecture ”: He's a design method , It contains multiple services , Services provide a series of functions through interdependence . A service Usually in a separate form with the operating system process . Between services Call... Over the network .

2. Microservice architecture : Actually sum SOA The architecture is similar , Microservice is in SOA The sublimation of doing , One of the highlights of the microservice architecture is “ The business needs to be completely componentized and serviced ”, The original single business system can be divided into multiple independent development systems 、 Design 、 Small applications running . These small applications interact and integrate with each other through services .

Microservice architecture = 80% Of SOA Service architecture ideas + 100% The idea of component-based architecture + 80% Domain modeling ideas

SOA Architectural features ：

• System integration ： From the point of view of the system , Solve the communication problem between enterprise systems , Scatter the original 、 A network of unplanned systems , Comb into Be regular 、 Governable inter system star structure , This step often requires the introduction of Some products , such as ESB[ Enterprise service bus (Enterprise Service Bus)]、 And technical specifications 、 Service management specifications ; The core problem to be solved in this step is 【 Orderly 】

• The service of the system ： From the perspective of function , Abstract business logic into Reusable 、 Services that can be assembled , Realize the business's Fast regeneration , Purpose ： Transform the original business functions into general functions Business services , Fast reuse of business logic ; This step solves The core issue is 【 Reuse 】

• The service of business ： From the perspective of enterprises , Abstract the functions of an enterprise into Reusable 、 Services that can be assembled ; Transform the original functional enterprise structure into a service-oriented enterprise structure , Further improve the external service ability of the enterprise ;

• “ The first two steps are to solve the system call from the technical level 、 The problem of system function reuse ”. The third step , It is to encapsulate a business unit into a service with business driver . The core problem to be solved in this step is 【 Efficient 】

Microservice architecture features ：

1. Componentization through services

Developers no longer need to coordinate the impact of other service deployment on the service .

2. Divide service and development teams by business capabilities

Developers are free to choose development technology , Provide API service

3. De centralization

• Each microservice has its own private database to persist business data

• Each microservice can only access its own database , And can't access the database of other services

• In some business scenarios , Need to update multiple databases in one transaction . In this case, the database of other microservices cannot be accessed directly , But by operating on microservices .

• Decentralization of data , Further reduce the coupling between microservices , Different services can use different database technologies （SQL、NoSQL etc. ）. In a complex business scenario , If there are multiple microservices , Usually in the client or the middle layer （ gateway ） Handle .

4. Infrastructure Automation （devops、 Automated Deployment ）

Conventional Java EE Deployment architecture , Package through presentation layer WARs, The business layer is divided into JARs The final deployment is EAR A big bag , And microservice opens the black box , Split the application into a single service , application Docker technology , It doesn't depend on any servers or data models , It's a full stack application , It can be deployed independently through automation , Each service runs in its own process , Contact... Through lightweight communication mechanisms , Often based on HTTP resources API, These services are built on business capabilities , Can achieve centralized management （ Because there are so many services , Without centralized management, we can't DevOps La ）.

The main difference ：

2. Remote call mode

Whether it's microservice or SOA, Are facing remote calls between services . What are the remote invocation methods between services ？

There are several common ways of remote calling ：

• RPC：Remote Produce Call Remote procedure call , Similar to that RMI. Custom data format , Based on the original TCP signal communication , Fast , Efficient . In the early webservice, Now the hot dubbo, All are RPC Typical

• Http：http In fact, it's a kind of network transmission protocol , be based on TCP, It specifies the format of data transmission . Now the communication between the client browser and the server is basically Http agreement . It can also be used to make remote service calls . The disadvantage is that the message package is bloated .

Now the hot Rest style , You can go through http Protocol to implement .

2.1. know RPC

RPC, namely Remote Procedure Call（ Remote procedure call ）, Is a computer communication protocol . The protocol allows programs running on one computer to call subroutines of another computer , And programmers don't have to program for this interaction . To put it more popularly, it is ：A Computers provide a service ,B A computer can call... Just like a local service A Computer services .

Through the above concept , We can know , Realization RPC Mainly to achieve two points ：

Implement remote call to other computer services

To implement remote call , It must be transmitting data through the network .A The program provides services ,B The program passes the request parameters to A,A Local execution results , Then return the result to B Program . There are two points to pay attention to here ：

• What kind of network communication protocol is used ？

Now more popular RPC frame , Will adopt TCP As the underlying transport protocol

• What is the format of data transmission ？

The two programs communicate , The data transmission format must be agreed . It's like two people talking , In the same language , Otherwise you can't communicate . therefore , We must define the format of the request and response . in addition , Data transmission in the network requires serialization , Therefore, we need to agree on a unified serialization method .

Call a remote service as if it were a local service

If it's just a remote call , Not yet RPC, because RPC The emphasis is on procedure calls , The procedure called should be transparent to the user , The user should not care about the details of the call , You can call a remote service just as you call a local service . therefore RPC Be sure to encapsulate the called procedure

RPC Call flow chart ：

Reference link ：

• blog.csdn.net/zpoison/article/details/80729052

• www.dockone.io/article/394

• qinnnyul.github.io/2018/08/20/microservice-design-principal/

recommend

Main stream Java Advanced technology （ Learning material sharing ）

Java Interview questions

Join in Spring Technology development community

PS： Because the official account platform changed the push rules. , If you don't want to miss the content , Remember to click after reading “ Looking at ”, Add one “ Star standard ”, In this way, each new article push will appear in your subscription list for the first time . spot “ Looking at ” Support us ！