当前位置:网站首页>This is probably the most hardcore microservice guide you've ever seen!

This is probably the most hardcore microservice guide you've ever seen!

2020-12-07 13:35:45 Alice

Preface

         In recent years, micro services have become very popular , Everyone is building microservices , I don't want to talk about microservice related technologies , Not so mainstream .

         In recent years, many companies and teams that have seen friends around them are trying to change their microservices , But many teams don't have actual micro service experience , Many teams even force to go to microservices for microservices , Finally, it is written as a large-scale distributed monomer application , It means that the transformed system has no rapid expansion of microservice , Flexible release features , It also makes the original monomer application lose the convenience of development , Deploy easy features ( The project is divided into several parts , The complexity of development and deployment has increased ), It has to be said that the gain is not worth the loss .

         The author has personally experienced and participated in the transformation and construction of several large-scale projects . So I want to share my experience on micro services with you as a practitioner , Help you understand the advantages and disadvantages of microservices and some development principles , In this way, we can make more appropriate choices in combination with our own business .

        (PS: Because there are so many tutorials on how to use the microservice framework tool , So this is just a general overview of microservices , There are no tutorials on the installation and use of various microservice frameworks , We only talk about the advantages and disadvantages of the design pattern of microservices and the applicable scenarios )

What is microservice ? Why use microservices ?

         What is microservice ?( Familiar students can directly skip )

         generally , Microservice architecture is a kind of Architecture mode Or a kind of Architectural style .

         It advocates Divide a single application into a set of small services , Each service runs independently of its own process , Services coordinate with each other 、 Cooperate with each other , Provide the ultimate value for users .

         Between services Lightweight communication mechanisms communicate with each other ( Usually based on HTTP Of RESTful API). Each service is built around a specific business , And can be independently deployed to the production environment 、 Class production environment, etc .

         A simple example : All the students who read military news should know , Although an aircraft carrier has a strong combat capability , But the weakness is too obvious , It's just that the defense is too poor , Single aircraft carriers rarely operate alone , Usually aircraft carrier battle group is the main military force , You can think of a single carrier as a single application ( Poor defense , Poor mobility ), Take the carrier battle group ( Scheduling is complex , Maintenance costs are high ) Understand as microservice .

Differences between microservice architecture and monomer architecture

A. Monomer architecture

         informally ,“ Single application (monolith application)” It is to package all the functions of the application into a single unit , It can be JAR、EXE、BIN Or other filing formats .

 Insert picture description here
Monomer application has the following advantages :

        1、 Simple and direct development , Centralized management , Basically no re development

        2、 The functions are all local , There is no distributed administrative and invocation overhead

Its shortcomings are also very obvious , Especially for Internet companies :

        1、 Low development efficiency : All development changes code in one project , Submit code to wait for each other , Code conflicts

        2、 Code maintenance difficulty : Code functions are coupled together , The new guy doesn't know where to start

        3、 Inflexible deployment : Long build time , Any small changes must rebuild the entire project , The process is often long

        4、 Low stability : A trivial little problem , Can cause the entire application to fail

        5、 Insufficient scalability : Unable to meet business requirements under high concurrency

 Insert picture description here

B、 Microservice architecture

         With the rapid development of business requirements , agility 、 The demand for flexibility and scalability is growing , There is an urgent need for a faster and more efficient way of software delivery . Microservice is a kind of software architecture style that can meet this demand . Monomer applications are broken down into smaller Services , Each service has its own archive , Separate deployment , And then together they make up an application . there “ tiny ” Not for the number of lines of code , Instead, the scope of services is limited to a single function .

 Insert picture description here
Microservices have the following advantages :

        1、 Microservices are loosely coupled , Both in the development and deployment phases are independent .

        2、 Fast response , Local modification is easy , A service failure will not affect the entire application .

        3、 Easy integration with third-party application systems , Support development in different languages , Allows you to take advantage of the latest technology .

        4、 Each microservice is small , Enough cohesion , Small enough , The code is easy to understand . The team can pay more attention to the results of their work , Focus on specific business functions or business requirements .

        5、 Development of simple 、 Improve development efficiency , A service may be a single thing , Can be developed by small teams alone , This small team can be 2 To 5 The group of developers .

alike , There are also the following shortcomings :

        6、 Microservice architecture brings too many operation and maintenance operations , The team may need to have a certain amount of DevOps skill .

        7、 Distributed systems can be complex and difficult to manage . Distribution deployment tracing is difficult . As the number of services increases , Increased management complexity .

The main features of microservice Architecture

         Microservice architecture is a kind of Loosely coupled 、 Service-oriented architecture with a bounded context . in other words , If you encounter a function change , But it requires every service to be modified at the same time , Then they can't be called Microservices , Because they're tightly coupled ; If you need to master the context of a service, scenario usage conditions , Then it is a context-bound service , This definition generally comes from DDD( Domain-driven design ).

Its main characteristic is componentization 、 loose coupling 、 autonomous 、 De centralization , Reflected in the following aspects :

A. Fine grained service decomposition

         Service granularity should be small , Each service is an encapsulation of business capabilities for a single responsibility , Focus on doing one thing well .

B. 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 .

C. Independent development and evolution

         Flexible technology selection , Not constrained by legacy system technology . Selecting the right technology for the right business problem can evolve independently . Service to service to take between language - independent API To integrate . Relative monomer architecture , Microservice architecture is a more business-oriented architectural pattern .

D. Independent teams and autonomy

         The team is responsible for the entire lifecycle of the service , Work in a separate context , Make your own decisions and govern yourself , There is no need for a unified command center . Teams are connected to each other through loose community tribes .

         By decoupling what we do , Divide and conquer to reduce unnecessary wear and tear , Enabling complex systems and organizations to respond quickly to change .

What principles should be followed when using microservices ?

         The ancients said : The troops did not move , Gateway leading . Building microservices requires long-term planning , It's not like writing CMS Build the database table like that , Then I started to work , In all likelihood, it will fail . Before we carry out microservice transformation , Architects should plan ahead , Let's divide this into three steps , Early stage , design phase , Technical stage .

Early stage , We should do the following things :

  • Communicate fully with all parties , Make sure to meet the needs of customers and organizations , And get approval
  • Communicate with the team , Let your teammates ( Development / test / Operation and maintenance ) understand , And actively engage in
  • Communicate with business department , Specify the version plan and launch time

design phase , Reference resources Sam Newman Works 《 Microservice design 》, Single micro service must meet the following conditions , To meet the basic requirements of microservice :

  • The standard REST Style interface ( be based on HTTP and JSON Format )
  • Independent deployment , Avoid sharing databases ( Avoid affecting the whole distributed system due to the database )
  • High cohesion in business , Reduce dependence ( Design to avoid too much or too little service )

Huge distributed system , Need strong infrastructure to support , What infrastructure does microservice involve ?

  • CI/CD And automation ( It's almost impossible for a distributed system to be released manually )
  • Virtualization technology ( To ensure the isolation of microservice operation environment , At present, the mainstream of the industry is the use of Docker Containers )
  • Log aggregation , Full link monitoring ( Highly observable and analyzable to diagnose problems )

Questions to consider

        1、 The code amount of a single microservice is small , Easy to modify and maintain . however , The total amount of system complexity is constant , Each service code is missing , But there must be more services . It's like a jigsaw puzzle , The more you cut it , The harder it is to make the whole picture . A system is broken down into fragmented microservices , Finally, it needs to be integrated into a complete system , Its complexity is definitely much higher than that of large-scale functional integration .

        2、 Single microservice data is independent , It can be deployed and run independently . Although microservices themselves can be deployed and run independently , But still can't avoid business you come and go , This involves external communication , When the number of microservices reaches a certain order of magnitude , How to provide an efficient cluster communication mechanism has become a problem

        3、 A single microservice has its own process , The process itself can start and stop dynamically , Lay the foundation for seamless upgrade , But who's going to start and stop the process , When , Choosing which device to do this is the key to seamless upgrade . This capability is not provided by the micro service itself , It requires strong version management and deployment capabilities behind it .

        4、 Multiple identical microservices can be used for load balancing , Improve performance and reliability . It is because the same microservice can have multiple different instances , Make it possible for services to scale dynamically on demand , In the peak period, more micro service instances can be started to serve more users , In order to improve the response speed . At the same time, this mechanism also provides high reliability , After a microservice failure , Other identical microservices can take over its work , External performance for a certain equipment failure after business interruption . Same thing , Microservices themselves don't care about system load , So when should we start more microservices , How to schedule and distribute the traffic of multiple microservices , There is also a complex load monitoring and balancing system at work .

        5、 Microservices can be deployed independently and provide services to the outside world , The business online and offline of microservices is dynamic , When a new microservice comes online , How users access this new service ? This requires a unified entrance , New services can be dynamically registered to this portal , Users can get the access address of all services of the system from this portal every time they visit . This unified system portal is not part of the microservice itself , So this capability needs to be provided by the system alone .

        6、 There are also some system issues of concern at the enterprise level , such as , How to manage security policy centrally ? How to quickly audit and track system failures to specific services ? How to monitor the state of the whole system ? How to manage the dependencies between services ? And so on, these issues are not considered by a single microservice , And there needs to be a systematic consideration and Design , Let each micro service provide corresponding security according to the systematic requirements and constraints , reliability , The ability to maintain .

Choose the focus of the microservice framework

        1、 Service registration 、 Find out 、 Load balancing and health checks : Suppose you use in-process LB programme , Then service self registration is generally done in the server-side framework , Health check logic is customized by specific business services , The framework layer provides a mechanism for invoking health check logic , Service discovery and load balancing are integrated into the service client framework .

        2、 Monitoring log : On the one hand, the framework should record important framework layer logs 、metrics And call chain data , And the Journal 、metrics When the interface is exposed , Let the business layer record business log data as needed . In the running environment , All log data is generally centralized landing in the enterprise background log system , Do further analysis and processing .

        3、REST/RPC And serialization : The framework layer should support the business logic to HTTP/REST perhaps RPC The way it's exposed ,HTTP/REST It's the current mainstream API Exposure mode , In the case of high performance requirements, it can be used Binary/RPC The way . For the current variety of equipment types ( browser 、 Ordinary PC、 Wireless devices, etc ), The framework layer should support customizable serialization mechanism , for example , On the browser , The framework supports output Ajax Amicable JSON The message format , For internal services and Applications , The framework supports high output performance Binary The message format .

        4、 To configure : In addition to supporting normal configuration file configuration , The framework layer can also integrate dynamic runtime configuration , The ability to dynamically adjust service parameters and configurations for different environments at runtime .

        5、 Current limiting and fault tolerance : The framework integrates current limiting fault-tolerant components , It can automatically limit current and fault tolerance at runtime , Protection services , If further combined with dynamic configuration , It can also realize dynamic current limiting and fusing .

        6、 Management interface : Framework integration management interface , On the one hand, you can view the internal status of the framework and services online , At the same time, it can also dynamically adjust the internal state , For debugging 、 Monitoring and management can provide quick feedback .Spring Boot Microframe Actuator Module is a powerful management interface .

        7、 Unified error handling : For framework layer and internal exception of service , If the framework layer can handle and log uniformly , It is very helpful for service monitoring and quick problem location .

        8、 Security : Security and access control logic can be encapsulated in the framework layer , Can be made into plug-in form , Specific business services load relevant security plug-ins as required .

        9、 Documents are generated automatically : Document writing and synchronization has always been a pain point , If the framework layer can support the automatic generation and synchronization of documents , Will be used API It's very convenient for developers and testers .Swagger It's a fashion Restful API Document scheme for .

therefore , A complete microservice system , It should contain at least the following functions :

        1、 Logs and audits , It's mainly a summary of the logs , Sort and query

        2、 Monitoring and alarm , It's about monitoring the status of each service , Alarm when necessary

        3、 The message bus , Lightweight MQ or HTTP

        4、 Registration found

        5、 Load balancing

        6、 Deployment and upgrade

        7、 Event scheduling mechanism

The following features are not part of the minimal set , But it should also be considered in the choice :

        1、 Authentication and authentication

        2、 Multilingual support , Whether it supports multiple programming languages

        3、 Unified service building and packaging

        4、 Unified service testing

        5、 Unified profile management

        6、 Service dependency management

        7、 Problem tracking debugging framework

        8、 Grayscale Publishing

        9、 Blue and green deployment

        10、 Resource management , Such as : The bottom container , virtual machine , Physical machine and network management

The way development affects

         With the spread of the concept of continuous delivery and the concept of containers , Microservices combine these two concepts and technologies , To form a new Microservices +API + Container platform Development model , The concept of continuous delivery of containerized microservices is proposed .

         The figure below shows the traditional monomer application DevOps How to develop the team :
 Insert picture description here
         This holistic architecture requires a product team across product management Dev Development QA DBA And system operation management , After the introduction of microservice Architecture , Here's the picture :

 Insert picture description here
         Microservices promote DevOps The restructuring of the way , Divide a large and bulky overall product development team into product teams according to different microservices , And a large overall platform team is responsible for operation management , Between the two API Interaction , Loose coupling isolation is achieved .
 Insert picture description here

Summary

         There are certain preconditions for the implementation of microservices : Basic operation and maintenance capability ( Such as monitoring 、 Quick configuration 、 Rapid deployment ) Need to build ahead of time , Otherwise, we will fall into a passive situation .

         Recommend CI/CD Practice of improving infrastructure and operation and maintenance , Through automatic operation and maintenance, it can quickly and safely respond to and handle the requirements of microservices for service deployment , Through container technology to ensure higher consistency between service environments , Reduce “ Working in my environment , And your environment doesn't work ” The possibility of , It also provides better support for the follow-up release strategy and operation and maintenance .

         Want to better implement microservices , First you need to think about building a team DevOps Ability , This is the source of power to ensure the continuous delivery of microservice architecture and deal with complex operation and maintenance problems ;

         Second, keep the service evolving , Make it fast 、 Low cost split and merge , Rapid response to business change ; At the same time, keep the team and architecture aligned . Microservices seem to be a technological revolution , But it has a strong impact on team structure and organizational culture . Identifying and building teams that match architectures is another pillar of problem solving .

         Last , Building an organizational culture of continuous improvement is the key cornerstone of the implementation of micro services . Only continuous improvement , Continuous learning and feedback , Continue to build such a cultural atmosphere and team , Microservice architecture can continue to develop , Keep it fresh , In order to achieve our original intention .

This reference is :
[1]: The concept of micro service and its advantages and disadvantages https://blog.csdn.net/kunyus/article/details/90670710
[2]: What is microservice https://www.cnblogs.com/xiao2shiqi/p/11298663.html
[3]: What is microservice architecture https://www.zhihu.com/question/65502802

         Those who benefit from it remember that Sanlian supports Xiaojun !

Articles are constantly updated , You can search through wechat 「 Ape man fungus 」 First time reading , Mind mapping , Big data books , Big data high frequency interview questions , A large number of first-line and large-scale factories face to face … Looking forward to your attention !

版权声明
本文为[Alice]所创,转载请带上原文链接,感谢
https://chowdera.com/2020/12/20201207133434084v.html