Some opinions on microservices

Refactoring the process

The figure above shows the whole product development cycle , The function list and blueprint of the product are the goals of the whole refactoring , Need to be clear , And relevant documents , Otherwise, refactoring is easy to deviate . And we should control the time node of the reconfiguration , If refactoring is far away , The goal continues to be delayed . Will affect the company's revenue and costs , Maybe the actual income is better than not reconstructing .

Refactoring is divided into local refactoring and global refactoring , Our business scenario belongs to overall reconfiguration , When the whole is reconstructed , It is easily influenced by the historical system , The impact of historical baggage . But I personally think that if the overall reconstruction , Also consider historical issues , For example, copy the code from the original system 、 Consider compatibility , These are not desirable , It's easy to extend the original problem to the new system , So the above refactoring is basically no different from developing a new product .undefined The whole process is based on B End products as an example , And some contents are omitted , Such as listing evaluation , But the main process does not matter B End C End , It should be similar in general .

The picture above is that I will 100 Multiple sheets PPT and 10 Integration of multiple documents , Each link has specific input , It cannot be shown to you for confidentiality reasons . The orange part is actually the whole agile development system , Agile content is also omitted for the sake of process clarity , So there are a lot of contents in this picture , You can take a closer look .

Refactoring strategy

Deployment strategy

Before refactoring , You need to figure out the overall system architecture 、 Deployment architecture, etc , If something goes wrong with the underlying design, it will be disastrous , Because it is based on the bottom layer , First, the workload is huge , Second, it may be for compromise , Doing a lot of compatibility processing leads to refactoring failure . Unable to achieve the goal .

Because our service is the back end Api Provides access interfaces in the form of , So there are many kinds of front-end applications , Like our CS client 、 Official website page 、 Inside CM Website, etc . The figure shows the process and deployment of users accessing these three applications .

• Users visit the official website undefined user -> Initiate a request to access the official website -> adopt nginx To configure https Forward to the official website application -> The official website application is licensed from Pod Pull certificate -> adopt CA Public key certificate verifies user login -> The customer normally accesses the official website application -> The official website application accesses the service to be accessed through the gateway （ We actually access other services directly on the official website , No gateway , I don't recommend ）
• User access to client applications （ Like a computer QQ）undefined user -> Log in to the client -> adopt nginx To configure https Forward to authorization Pod-> The client is authorized from Pod Pull certificate -> adopt CA Public key certificate verifies user login -> Customer login successful .undefined Because the client involves a lot of microservices , Therefore, there may be situations where the microservices are not completely migrated , New services and old services （ Interface ） Coexistence . So for different operations , We go through nginx Forward , If the client related operations have completed the migration of the new service, use nginx Forward it to the gateway , The gateway service requests other services , Return the data to the client . If the client related operations have not completed the migration , be nginx Forward it to the old service , The old service returns the data to the front end .
• User access CMundefined User access CM Visit the official website with the user , So I won't go back to

This deployment strategy is a simplified version , For example, high availability is not shown , Unrealized serviceMesh, The services that the back-end application depends on are not shown , Such as kafka、mongo、es、redis etc. . This article is to make it easier to understand , And our first version of the service has not yet been implemented serviceMesh, Other dependent kafka、mongo And other deployment strategies , The deployment of different business scenarios is also different, so , Show only the main structure .

Normally, the service route should be forwarded through the gateway , But because of some early design and other reasons, we put the routing function directly in nginx, Gateway service Pod It can be used as a strengthened BFF.（ Students with weak foundation , There may be some doubts here , Maybe I saw the tactical design , It's clear here ）

Spin off strategy

The transformation of microservices is not achieved overnight , Because the whole project quantity is relatively large , So we will face several problems .

• How to ensure the normal operation of online business , At the same time, complete the transformation and launch of the service ？
• If there is a problem after the service goes online , How to quickly roll back ？
• How to ensure that there are no large-scale accidents after the service goes online ？undefined In view of these problems , The rough solution we came up with was ：

, No matter what mysql、mongo Or what , Their migration ideas are basically the same .

• Because the old database and the new database are maintained at the same time , Old services and new services also survive at the same time , When there is a problem, you can switch directly nginx Fast application switching . After the new service runs stably for a period of time , You can stop the old service . If there is a problem with the new service later , You can use k8s Rolling update mechanism of , Switching the image can facilitate rollback .
• In order not to cause large-scale accidents , New services can only be launched in batches , Try to control the scope of influence . Therefore, the newly launched services cannot rely on other services , For example, first launch the authorization service 、 Verification code service and other basic function services . So service transformation , Start with basic services , After the basic services are completed , Then carry out service transformation that depends on basic services

Release strategy

We talked about how to start from 0 To 1 Build your own enterprise for internal use devops, alike , The original application has been transformed through microservice , It has been split into dozens or hundreds of microservice applications , It is impossible to publish through human flesh , So we use devops Automatically publish .

image.png

We start with git Warehouse pull code , Then the code is scanned , Code analysis then generates images , Publish to test environment K8s colony , After passing the test by the tester , We pull images from the image warehouse , Publish to pre launch environment , Another round of simple test is conducted in the pre launch environment , After passing the test . Pull images from the image warehouse and publish them to the official k8s colony .

Maybe for this release process , There are still many questions . For example, some of my warehouse code is deployed one day 1000 Time , Do I want to keep the image warehouse 1000 individual

Mirror version ？ So many mirrors , How do I know which images are stably released in the official environment , Which are the test images ？ Hundreds of services , I jenkinsfile Every microservice project has one ？ If you modify and maintain jenkinsfile Not every project needs to be changed ？ How to publish rollback ？ Blue green 、 How do I get the grayscale ？ How to deal with development branch management ？

Image management

Image management .png

We marked all the unofficial images as Tag:latest, In this way, my image repository has only one image for testing , Version is latest, Avoid too many images in my image warehouse , It also avoids me k8s Cluster server , Too many mirrors cause the disk to fill up . When the test passes , We use it jenkins When publishing , Check “tagOfficialImage” This check box , In this way, we will make a tag,tag The format is “ edition . date .git Submit the number ”. meanwhile git On the code , Put the same tag.

In this way, we will pre release 、 When it's officially released , find git The latest in the project tag, because git、 Mirror image tag The same name , So we released the latest image . If you want to roll back , Empathy ,jenkins Select the corresponding git Project tag, According to this tag Go to the image warehouse to find an image with the same name and roll back to the corresponding version .

Branch management

because git There are many types of branches . We are divided into the following categories ： Iterative development branch （12Sp2）、 Repair branch （hotfix）、 Special branch （feature）、 The main branch （master）. commonly ,master Branch as the main branch , Need stability and security , Therefore, general developers are not allowed to directly push code to master Branch . So at the beginning of each iteration, a new branch is created according to the iteration date , such as 12 Yue di 2 An iterative , Just add branches 12Sp2. At the end of the iteration , Again by SM To be approved 12Sp2 Code merge to master, At this time, it is stable for the customer master Code for .

In the test environment jenkins When publishing a deployment , Just use 12Sp2, Because there will be repeated modification and debugging during the development process . If you use master Branch , Change one BUG need SM Review the code once , Oneness code , Developers and testers have to wait for the code to merge , To retest , Cause great internal losses . and 12Sp2 To change a , Release once . Truly achieve continuous deployment , Wait until the test passes , Just merge the code master, And fight tag To publish , This requires only one code merge audit .

jenkinsfile management

To configure pipeline You need to configure one in the project Jenkinsfile file , Deposit pipeline Script ( Don't consider job Writing scripts directly in , Maintenance is too cumbersome ). Maybe many students will think of it at this time shared

library. however shared library It can only solve the problem of function reuse , Not solve jenkinsfile The problem of reuse . So I refer to this

As for grayscale Publishing , have access to nginx, It can also be used directly k8s Of ingress, Essence is also nginx. The blue-green release only divides the traffic into different k8s colony . Because this has not been practiced yet , So I won't go into details , So as not to mislead , But it doesn't feel complicated , Online information , Believe in smart you , It should be enough .