This article is the fourth in Boyun micro service transformation series.
In the first three articles in this series, we shared the troubles, misunderstandings and the first step of microservice transformation. When talking about microservices before, we shared many landing schemes and practice summaries, but rarely mentioned the concept of microservices. The reason is that only talking about ideas is a little empty, and the stage of speculation about ideas has passed. But up to now, we have to take out the concept and use the concept to guide the direction of our micro service construction.
This is because if anything wants to have a deeper and longer-term development, it usually needs the guidance of philosophy or ideas. Just like the impact of western philosophy on modern society, even the high-level programming language skillfully used by everyone also uses the abstract and logical ideas of western philosophy, and then there are technologies such as class and layering. So in the construction of micro services, how should we use the concept of micro services to realize the implementation of micro service construction without deviating from the overall cloud original goal?
01 micro service concept
The concept of microservice became active around 2017, and then entered a process from imagination to landing. Everyone gradually tried and gradually fell into trouble, because the gap between practice and ideal is still very far. By this year, almost all enterprises are considering the construction of digital transformation, which is the general trend. If they can maintain clear ideas in the current IT construction and future cloud primary route planning, such enterprises are really valuable. Maybe this article can give some inspiration to the confused builders, but “the use of the wonderful, keep one mind”, the specific construction situation should be carried out according to the current situation of the enterprise.
Let’s first look at the concept of microservice. You can find a lot of data by searching the Internet. The statements are basically unified: instead of a bulky system, you rely on a new technical architecture to split the system into multiple independent components. The degree of independence represents the degree of freedom of each microservice component. The higher the degree of freedom, the more possibilities. The main advantages can be as follows:
Independent operation and deployment can naturally be upgraded, changed and maintained independently, and the capacity can be expanded and reduced freely according to its business volume. Moreover, the operation unit is small, the waste of natural resources is small, light and fast.
If it can run independently, it can be developed independently. In this way, it can be decoupled in the technical architecture. As long as the service contract is followed and the corresponding interface is provided, the technology, language and data storage used in the development can be built independently. In other words, if you need to rely on a service with different development framework and language, you only need to understand the interface and protocol, and you don’t need to pay attention to others.
Can develop independently, then the development team can manage independently, so the management efficiency is much higher.
There are many advantages of microservices, but these three are the most important and have the greatest impact on the overall management of the enterprise. However, it is difficult to achieve such an ideal goal in the short term.
If you look at a system, it is easy to split it into multiple microservices and run and deploy it independently. This is also the scenario I mentioned in my misunderstanding. However, for the construction of the whole enterprise and bank, we should consider that all systems can be disassembled into independently deployed microservices and can call each other. Of course, access control should be achieved at the same time. This requires bank wide unified planning, unified technical framework and communication protocol, and of course, a unified management platform for management in operation.
Independent development seems easy to realize, but it is the most difficult to use it well. Because the concept of design and development as a single system has been deeply rooted. When the system is disassembled into micro services, it is difficult to reverse the concept. Therefore, many micro service systems still evolve from system version to system version, and each micro service even has no version. This is the formal micro service, but in fact, the advantage of independent update has not been brought into play. New ideas need technical architecture, technical management and technical R & D, and gradually accept, reverse and habits, which are difficult to change in the short term.
Independent development teams or groups need to adjust the administrative structure, so this step is also the most difficult to change. From the perspective of management, the communication cost of three people is the lowest. Therefore, in the most scientific management method, the smallest management unit is three people. The management of huge business system in R & D is also faced with the problem of low communication and management efficiency. Microservices provide the possibility to optimize their management, but they also need to be gradually adapted and changed.
In short, it may take a long time to build, change and adapt to the ideal micro service. I’m afraid this process can’t be saved. It’s just how to go and where to start?
02 road of micro service construction
After the microservice is embodied, it is the microservice framework. After all, the implementation of all ideas is based on the microservice framework. The microservice framework solves the technical problems after the independence of microservices, such as communication, addressing, current limiting, etc. Therefore, the microservice system first needs to develop and use the microservice framework. Based on this, it is designed. When the development stage is completed, it can naturally be deployed into a microservice system at runtime. During the operation of microservices, it needs operation observation, policy configuration, problem debugging, etc. This is the use process of the whole set of microservices.
However, the construction process of microservice is also in this order when it is used, so it is difficult to build it. Next, according to our company’s construction experience in many micro service projects, sort out the content and order of micro service construction. First, what needs to be built for the construction of micro services:
As mentioned in the previous article, the construction of microservices requires a unified technology stack, that is, a unified technical architecture, technical components, communication protocols, communication messages, etc. After unification, it can be easy to manage, plan from the overall situation and optimize the architecture design. The R & D department avoids many complex transformations due to different technologies; The operation and maintenance department will also reduce the operation and maintenance workload and save server resources because all systems use the same set of governance components. Therefore, formulating and promoting specifications is the first step of construction, including the construction of basic components.
- The microservice running state, that is, the running microservice system in the test and production environment, serves as a management platform for governance, observation and configuration. The advantages of microservices also bring many disadvantages, such as too many services are difficult to manage, problems are not easy to locate, their dependencies are not clear, policy changes are difficult to operate, and so on. Then the operating observation platform or support platform is to solve all problems in operation, including change release, operation and maintenance monitoring, log viewing, etc.
- Microservice development status and specifications are set for development and deployment, such as standard protocols, standard messages, fixed component addresses, fixed probes, etc. Therefore, during development, SDK needs to be introduced, annotations need to be inserted, and conflicts between dependent packages need to be solved. Of course, service contract is also an important part, which is also related to design. Usually, service contract is the result of design and is also used to test the quality of development. Once things are in-depth, they will be complex. Usually, a micro service development support platform will be built as the management of development status.
- Unified release management. One deployment package shuttles through multiple environments. Each deployment requires special operation and maintenance, complete deployment scripts or documents, and the addresses of various components need to be configured again and again. This work is really a little huge. Therefore, we need a product library that can manage multiple environments, support container and non container application deployment, and can connect and manage different environments for the same publishing and deployment platform.
Many people may be confused about such construction. Why not start from the development state, build from the operation state, then the development state, and finally supplement the intermediate release and deployment? This is the experience we have gained from the practice of many projects so far. The concept of micro service has been put forward for so long. Now people in the IT industry basically have some understanding and understanding, but we should recognize that what we see is only the tip of the iceberg, and gradually build, gradually understand and gradually learn, Can we really understand the advantages and disadvantages of microservices.
If the construction starts from the operation state, the management of the development state can only be standardized offline, but the operation state is relatively fixed and easy to see. Therefore, the possibility of overturning the construction content in the short term is very low. Through the construction of development status, it is easier to understand and avoid disadvantages after gradually seeing the architecture of micro services. However, if the construction starts from the development state, it will be affected by the component selection, operation mode, deployment architecture, network location, etc. in the operation state. It must be fully considered. As long as there is negligence, the content of the construction may be overturned.
Therefore, we should start with the operation state. After the construction of the operation state, we can basically determine which specifications and contents to pay attention to in the development state. Similarly, after the development status is built, many issues needing attention in release deployment have been summarized, and then a unified release platform of container and non container has been built. In this way, the system of basically micro service transformation has been clear.
clickBocloud bocloudLearn more about solutions