Huawei cloud Gao Hongxia: CBC microservice code Reconstruction & independent release practice

The guest |  Gao Hongxia     Arrangement | Yinhong Huang

Produce | CSDN Cloud native

2022 year 6 month 9 Japan , stay CSDN Cloud native series online Summit 8 period " Huawei cloud native practice and application summit " On , Gao Hongxia, a Huawei cloud digital platform technology expert, shared Huawei CBC A practical case of microservice code refactoring and independent release .

Watch Gao Hongxia's sharing video

CBC（Cloud Business Center） Cloud operation platform , Responsible for the trading platform and operation platform capabilities of Huawei cloud , Covering the official website 、 Order 、 charging 、CRM、 Business modules such as partner cloud , Involving hundreds of micro Services .CBC It can be understood as a large cluster , Each cluster is registered by a unified service 、 Issue and manage .

CBC The construction goal of is ： Realize service autonomy , Improve service maintainability 、 Extensibility , Demand can be launched independently , Don't walk in unison .

CBC Problems encountered

But in practice , We have some problems ：

• CBC There are some unmanageable “ Super micro Services ”, The definition of division is ： Have 100+ The interface of （API）,10W+ Line code microservices

• In service , Some interfaces and information change relatively frequently , Some are very stable , Although in the same service management , But the pace of change is inconsistent

• Domain model division is not clear , There is a shotgun modification , Modify a problem but introduce a new one

• CBC The version adopts train mode （ Integrated release deployment ）, All micro services are delivered at a specific pace （1 Months 2 A version ）, Joint commissioning 、 Go online together , Some requirements TTM Elongated

The reason for these problems , This is our analysis ：

• Domain ambiguity ： Before refactoring , Because unified deployment is adopted , So we pay less attention to domain models

• The interface is arbitrary ： Ambiguity in key areas , The interface design is very random . There is a super micro service before refactoring , Yes 300 Multiple interfaces , Interfaces cover each other , There is no unified design principle

• data clumps ： Because the interface is open at will , The relationship between the data is not clear

• Code hybridity ： Before refactoring , All data is in the same service , Different processes can be accessed directly 、 Use the data , The reusability of the interface is low , Maintenance costs are high . Unclear data relationships are reflected at the code level , Before hybrid refactoring , In addition to the interface layer , Other levels are almost nonexistent

• Rely on Complexity ： Because the code is mixed, the relationship between dependency and dependency is very complex , Before refactoring, it is not clear how most service dependencies are used and invoked , The code that calls other services is scattered 、 Difficult to manage , Because dependence is complex , So all the services can only go in one step

• Inefficient deployment ： Before refactoring , The Bi weekly train version will be launched uniformly , Resulting in inefficient deployment

• The deployment platform does not support the streaming test of a single microservice

• UT It is difficult to write too little

• Loose modification ： Pull one hair and move the whole body

To solve these problems , We have restructured the service 、 Try to improve engineering ability and other aspects , The independent publishing architecture of microservices has been established , Finally, the service can be released and deployed independently at a self paced pace , It solves the problem of service maintainability 、 Extensibility , Improved delivery efficiency , Reduced service learning 、 maintain 、 Test cost .

The following focuses on service reconfiguration 、 Two parts of engineering capacity improvement practice .

Service refactoring

One 、 Domain-driven design ：DDD Large scale context segmentation & Domain modeling

The goal is ： Divide by domain model , Realize the decoupling of business modules , Reduce shrapnel modification

measures ：

• Large scale context division according to business boundaries , Identify volatile and stable modules
  

• Sort out the dependencies between contexts , Build a domain model , Make input for the code architecture
  

Two 、 Code decoupling —— Clean architecture of code

The goal is ： When the refactoring is complete , Ensure reliability and flexibility

measures ：

• introduce DDD Clean architecture , It is divided into entrance / exit 、 Business choreography layer 、 Domain layer
  

• implement “ The old is the same , New creation ; One step switch , Old goodbye ” The reconstruction technique of
  

• Introduce architecture testing , Ensure the stability of the architecture ; The new code will not break through the existing architecture
  

• Improve the coverage of white box testing , Reduce the difficulty of writing white box tests

3、 ... and 、API government —— Simplify the interface according to the domain model 、 Integrate

measures ：

• Divided by domain model , Peel off interfaces that are not within the scope of the art
  

• Classify by characteristics , Integrate interfaces with the same functional characteristics , From general 、 Scalable 、 compatible 、 Reasonably design the interface in terms of safety
  

• Review and summarize regularly , Ensure that the interface integration work follows “ analysis -> planning -> Rectification -> Offline ” To carry out in an orderly manner , Continuously improve and perfect the problems in the integration process , Forming a virtuous circle
  

After the above service reconstruction measures , Some preliminary effects have been achieved .

Engineering capacity improvement

One 、 Design the independent release and deployment process of microservices

Through the independent release pipeline 、 Microservice level blue-green deployment capability construction , Implementing microservice features E2E Release and deploy independently , Ensure the quality and efficiency of feature launch , At the same time, reduce the cost of multi branch synchronization and maintenance in version train mode .

• effect 1： The service currently supports both high and low versions , At the same time, it carries traffic
  

• effect 2：CBC Realize the drainage verification capability based on user list and user proportion
  

Two 、 Independently publish the deployment process （ The canary + Microservice level blue-green deployment ）

3、 ... and 、DevOps Adaptation and transformation of testing capability in the process

The goal is ： Build microservice test specification 、 Ability , Ensure that the quality of independent deployment of micro services does not decline .

• Changed development branch parallel development
  

• API Use cases are tested with multiple changes
  

• Have the ability of real-time interface test and evaluation
  

• Microservices can be carried out by themselves DFX test
  

• Microservices allow feature level testing
  

measures ：

• The interface design of different development branches can be carried out independently
  

• The ability to test multiple changes together
  

• Develop interface testing and evaluation pipeline plug-ins
  

• Develop microservice level DFX Test capability and pipeline plug-ins
  

• Define and deploy microservice feature level test environment

summary ： Practice can be replicated DNA

• adopt DDD The idea of clean architecture divides the context of services 、 Domain modeling and hierarchy , Ensure that different business modules do not invade each other , While maintaining the stability of the architecture . introduce ArchUnit Architecture testing takes care of code architecture
  

• Support blue-green drainage by micro service , Support each service to conduct independent testing of micro service blue-green drainage , Not disturbed by the blue-green drainage of other services
  

• API The use case can match multiple changes in the independent deployment mode to release the test of the deployment scenario ; Have the ability to test and evaluate the real-time interface of microservices

END

Cloud native volunteer program is recruiting

Accurately grasp the technology trend , Deep learning of new technologies 、 New practice

Scan the picture QR code and apply to join immediately

— Recommended reading —

* Jingdong Technology MA Junchang ： Microservice low code platform “ Star chain ” Application practice 

* Listen to Yang Jinquan, director of cloud R & D ： With Tracing As the core observability system 
* Past and present life and front-line practice of cloud native application delivery *2 Dimensions 5 The big way , Let your microservices in K8s Run up * Thoroughly analyze the application practice of cloud primitives in digital transformation ,PaaS " 

Click here ↓↓↓ Remember to pay attention to the target star

 One key, three links  「 Share 」「 give the thumbs-up 」「 Looking at 」
 100 million technical people