当前位置:网站首页>Design principles and core topics of microservice architecture

Design principles and core topics of microservice architecture

2021-10-14 06:39:26 xcbeyond

One 、 Preface

      without doubt , The design principles and core topics of microservice architecture are the focus of this paper , It is also the intention to build a microservice architecture from scratch 、 Planned . A good product 、 Whether the application can run stably , Continuous development , Meet business needs , Can stand the test of reality , It needs to be considered a lot in the design stage 、 quite a lot , To ensure its robustness .

    When we move from a single architecture application to a microservice based architecture , First of all, we will face a very difficult problem: how to split the services , How to measure the granularity of service splitting , How to split a service is “ tiny ”. And then there will be , How do so many services relate ? How to effectively communicate with each other ? How to deploy efficiently ……

      In this article, I will start from the design principles of microservice architecture 、 The core topic is discussed in two aspects , I hope it can help you to build a microservice architecture application .

Two 、 Design principles of microservice Architecture

      Design principles of software architecture 、 methodology , To a great extent can guide 、 Remind us what principles we should follow 、 standard , Can make software architecture more robust 、 Stable , And easy to develop 、 Expand 、 Maintenance, etc .

1. The split is small enough

      In solving complex problems , We tend to divide the problem into several small problems to solve , So-called “ Make a big deal small , It's trivial ”. Application of single architecture , as time goes on , It will become more and more bloated , It's getting harder and harder to maintain , Do it properly “ Subtraction ”, It can solve these problems of single architecture .

      When the application of single architecture is divided into the application of microservice Architecture , The granularity of service splitting , It has become a top priority . The granularity is too large , The split is not enough , It's not so different from single architecture , We can't give full play to the advantages of microservices . If the split is too thin , It will also face the service management caused by too many services 、 Problems with calls between services . For how “ tiny ” That's enough “ tiny ”, There is no standard method of measurement and calculation .

    Micro service doesn't mean that the smaller the better . The smaller the service , The advantages and disadvantages of microservice architecture will become more and more obvious . The smaller the service , The more independent the microservices are , But at the same time, the number of microservices will increase , There will be big problems in Management , Become a new challenge , This is often referred to as “ So many services , The service management ?” problem .

    The split of services is small enough , In some way 、 Rule split , Usually according to the business module 、 Split business scenarios, etc , Try to avoid interdependence between services , Achieve High cohesion and low coupling . A closely related process , Put it in a service , But avoid sharing data between services .

2. Lightweight Communications

      In the application of monomer Architecture , You can communicate directly through simple method calls , But in the microservice Architecture , Because services are cross domain processes , Even across hosts , Components can only pass through REST、Web Service or RPC Similar mechanisms communicate over the network .

      Because the service partition is small enough , Communication between services may be more frequent , Considering performance 、 Response time, etc , The lightweight communication protocol should be adopted in the communication between services , Such as : synchronous REST, Asynchronous AMQP、STOMP、MQTT etc. . In the scene of low real-time requirements , use REST Communication is a good choice ,REST Is based on HTTP agreement , It is convenient for cross domain access or cross firewall settings , And the message format can be unified as XML or JSON Format , Easy for developers to read and understand . If communication between services is frequent , There are relatively high requirements , Message communication can be used , Such as :Kafka、MQ And so on . If we don't consider providing external visits , May adopt gRPC Mode of communication , because gRPC Is based on Netty Of , More efficient communication .

3. Principle of single responsibility

      When the service grain is too thick , It's easy to have coupling inside the service . If multiple people develop the same service , It's easy to make code changes overlap due to too much coupling , Not conducive to later maintenance . Ensure that each service has a single responsibility , This is also a principle used to determine the boundary of service splitting , follow “ High cohesion 、 Low coupling ”.

    You have to know your products and business , In order to determine the service boundary more accurately , Enable services to meet a single business responsibility , Avoid overlapping responsibilities .

4. Domain Driven principles

      Domain-driven design (Domain Driven Design), It is a set of object-oriented modeling method for comprehensive software system analysis and design . A microservice , It should be able to reflect the domain model of a business , Use Domain Driven Design , It can not only reduce the complexity of general language in microservice environment , And it can help the team figure out the boundaries of the field , Clarify the context boundary .

    It is recommended to design each microservice as a DDD Bound context , It provides a logical boundary for microservices . Each independent team is responsible for a logically defined slice of the system , Responsible for all development related to a domain or business function , Finally, the code developed by the team is easier to understand and maintain .

( About DDD Learn more about , May refer to Domain driven design learning —DDD Principles and practice of - EdisonZhou - Blog Garden )

3、 ... and 、 The core topic of microservice Architecture

      Application based on microservice Architecture , There will be many options 、 Core topics of discussion such as disputes , These core topics will continue to appear in your next microservice architecture career , And become the focus of discussion . Here it is , I think it's necessary to summarize , Let you feel the necessity of its existence , Can be used for you .

1. Service split

        Service splitting focuses on the granularity of services , Design principles can be followed —— The split is small enough , adopt DDD( Domain-driven design ) Guidance of , Aggregate the functions of a domain into a service .

        For a large and complex monomer application , Choose which module to split first , It's a question . Generally speaking, it's easy first 、 Start with a simple split module , In the process of splitting simple modules , Constantly accumulate the experience of microservice , Gradually break down the complexity 、 The core module of heavy business . meanwhile , Look for those with low coincidence with other functions 、 Low coupling , And the basic services that change slowly , Break them up into microservices .

      Decide which modules to split , After splitting into multiple microservices , Next, we need to clear the boundary of service splitting , Make the service boundary and interface clear . Determine what should be included , What should not be included , Which interfaces need to be redesigned , What can be reused .

      As shown in the figure below , It shows the process of splitting a single application into multiple microservices . Once the split is complete , Services can be developed independently 、 Deployment and expansion .

      Service split , It's not just about splitting functions , As shown in the figure above , We also need to consider the split of the database  , Ensure that the functional logic layer is reduced 、 Data access layer coupling .

2. Service registration and discovery

      Microservice architecture is characterized by a large number of services , These numerous services need a unified service registration platform for service management . Every microservice instance is started , Register your instance information to the service registry or service registry . If the caller of the service wants to get the list of available service instances , You need to get the relevant information from the service registry .

      When a service instance fails or down After falling , The information of the service instance should be removed from the service registry , namely : Service sign out . The service registry is where all available service instances are maintained , On the one hand, the service registry should receive the access of microservice instance , On the other hand, when the service instance is not available , Need to clear the service instance from the registry in time . The following figure shows the relationship between service registration and service instance .

        Service registration and discovery components or frameworks , There's a lot of , Such as :Eureka、Consul、etcd etc. , All provide the function of service registry , You can choose .

3. Load balancing

        In the microservices architecture , Load balancing is a necessary technology , Through it to achieve high availability of the system 、 Cluster expansion and other functions . Load balancing is usually divided into two kinds : Server load balancing and client load balancing . Generally speaking, load balancing refers to load balancing on the server side , It can be realized by software or hardware devices , Software such as :Nginx、LVS etc. , Hardware such as :F5、A10 etc. , Hardware load balancing equipment costs more , Most of them are software . The architecture is as follows :

        Load balancing through software or hardware will maintain a list of servers , Use heartbeat detection and other means to maintain the list , Ensure that the list is full of service nodes that can be accessed normally . When a user sends a request , We'll get to the load balancer first ( Generally as a service ), Load balancer according to load balancing algorithm ( Training in rotation 、 Random 、 Weighted rotation ) Take the address of a server from the list of available servers , Then forward , Reduce the pressure on the system .

4.API gateway

        Considering the number of services in the microservice Architecture , In order to facilitate the unified management of external services ,API The introduction of gateways is essential .API The gateway is designed to provide a unified API entry point , To manage multiple services internally API, It is convenient to manage and control many service interfaces of the platform , Such as the identity authentication of access service 、 Business authentication 、 Traffic concurrency control 、API Called measurement or billing, etc .

      API Gateways are commonly used in the following scenarios :

  • Black and white list : To achieve, for example, by IP Address to disable access to certain functions of certain services .
  • journal : Log access records , Used to analyze access 、 Processing performance indicators , And provide the analysis results to other modules , Such as : Statistics function of operation and maintenance platform .
  • Protocol adaptation : Realize communication protocol verification 、 The function of adaptation conversion .
  • Identity Authentication : Responsible for access authentication of external system .
  • Current metering and current limiting : Realize the calculation of micro service access traffic , Based on the flow calculation and analysis, limit the flow, etc .
  • route :API The core function of the gateway , Implement request forwarding .

     API The introduction of gateway brings many benefits to the application of microservice architecture , as follows :

  • Avoid putting internal information / The interface leaks to the outside :  Be able to release API And micro services API Distinguish , Make each microservice add or change , There can be clear security boundaries , Avoid excessive external exposure .
  • Add additional security layer for microservices : Can provide an additional protective layer , In response to SQL Inject 、Dos Attack, etc , The authority control of the system can be implemented in this layer .
  • Support multiple mixed communication protocols : Considering the microservice Architecture , The platform and language diversity of various microservices , It will usually be based on HTTP or REST Of API Interface , The internal microservices will adopt different communication protocols according to their own service conditions ( Such as :ProtoBuf、RPC etc. ).API Gateways are cross domain micro services with different protocols , Provide one based on REST The unity of the outside API.
  • Reduce the complexity of building microservices : The complexity of application based on microservice architecture , Such as API token 、 Access control 、 Speed limit, current limit, etc , The addition of each function , Will have an additional impact on each service , This will affect the development cycle of microservices . If these functions are in API Unified processing on the gateway , It will be effectively isolated from the code level , So as not to affect other micro Services , In this way, other microservices only need to focus on the actual business development .

    common API There are many ways to implement the gateway , Such as :Nginx、Kong、Spring Cloud Zuul、Træfɪk etc. .

5. Service deployment and release

      After the monomer application is divided into microservices , As the number of microservices increases , Deployment becomes a problem , It makes deployment more complex . therefore , The deployment of microservices is more likely to use hosts with mutual isolation / Virtual machine to achieve the deployment of services , Enable services to be deployed independently 、 test 、 Release 、 upgrade .

    At present, a better way to deploy services is to package various micro services into Docker Mirror image , In this way, the impact of different host environments on deployment is avoided . Use Docker Deploy , And combine Jenkins Conduct CI/CD, Make build 、 Release 、 Start up faster .

    The figure below shows the service deployment 、 Publishing process .

 

Four 、 summary

        An application of microservice architecture , From the initial design to the gradual formation , It needs to go through continuous iterative development 、 Touch the rope to perfect , The above is just a list of what I personally think should be focused on , For your reference , If there is any omission , I hope you will suggest that 、 perfect .

 

版权声明
本文为[xcbeyond]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/10/20211002145418077o.html

随机推荐