It technology is increasingly innovative. When we share with customers how the chimney style single application is gradually split and evolved into SOA architecture, and how SOA architecture is completely split and evolved into micro service architecture, more new technologies and architectures are impacting our cognition.
The Internet industry is just like a leader on the technology track. Enterprises with many old application systems, such as resources, finance, transportation, banking and other industries, also have to strive to keep up with the pace of technology. However, where to start and how to transform have become their biggest worries.
We have been working on micro services for the fourth year“Operation support of sensitive service”After n times of practice, the micro service team in Boyun has stepped on countless pits. From microservice framework and API gateway to service grid and XX middle platform, from open source to self-developed, and from self-developed to open source, so many projects have come down. We think it’s time to seriously record and answer the questions about “digital transformation”. Just in combination with the recent projects of many rural commercial banks in Boyun, I would like to share with you some experience in the transformation of technical architecture.
The so-called “dual state it” in legend
Two years ago, there was a catchphrase called “dual state it”, which was put forward by Lenovo as a development strategy of “stable foundation, quick breakthrough” and harmonious coexistence. Steady state, usually refers to the system that can’t be transformed by micro service for various reasons, or single or SOA architecture; Sensitive state, of course, refers to the micro service architecture that can be transformed, that is, the main value range of our project.The so-called harmonious coexistence of two states actually refers to how the sensitive state system we want to build can be interconnected with the unmodified steady state system.In fact, this is the focus and difficulty of enterprise digital transformation.
Sensitive state: how sensitive is it
The core of digital transformation project is the design of technical architecture. New technology architecture is nothing more than container, micro service and other cloud native technologies. Therefore, using the concept of microservice, agile development, rapid integration and continuous release of container technology, such an architecture is our expectation – sensitive state.
Of course, as the core of the whole project, the design of technical architecture must be carefully studied, such as architecture selection, component selection, development specification, log specification and so on. Later, we will write a separate article to analyze the design of the specific technical architecture. In today’s article, we only talk about the key objectives and the overall strategy of the enterprise’s digital transformation.
Microservice technology should be earlier than container technology, but when container technology came to the stage, we found that this idea was the best carrier of microservice, so microservice also caught fire. As a result, many people who are not exposed to microservices think that there is a “causal relationship” between containers and microservices, but this is not the case.
In fact, many open-source microservice technologies, such as springcloud and Dubbo, overlap or even conflict with container scheduling kubernetes. The main problems are service registration discovery, network communication and load balancing. Of course, the corresponding solutions are easy to find, such as abandoning etcd for service discovery, using microservice registry components, using underlay network mode, etc.
In general, how sensitive is the sensitive state?First, services are gradually moved into containers to save resources and facilitate scheduling and managementThese two advantages are enough;Second, the business system will be gradually transformed into microservices, and a microservice architecture specification will be worked out in the next five years to transform each business system at the right opportunity。
So the question is, do you need to run the business system in the container platform while transforming the business system into a micro service? After our experience in many projects, it is almost self-evident when the project is not started, but it is often compromised in the process of the project. Because container transformation and microservice transformation are mostly started in different projects, container projects are generally driven by the operation and maintenance department, while microservice projects are often driven by the architecture department. In the case of tight project time, each has its own difficulties and wants to highlight the benefits, this kind of docking is a little strange.
But it doesn’t matter. Digital transformation is not only the transformation of technical architecture, but also the transformation of technical concept, including operation and maintenance mode, management mode, R & D mode, team operation mode and so on. Therefore, enterprises need to be prepared to “not be in place in one step”, and gradually learn and solve problems, so as to better take the road of transformation.
Steady state: steady as a stumbling block
In the process of microservice transformation, the biggest stumbling block is those non microservice systems, which are usually called old systems in projects. These systems are often the core or key systems in the bank.
The transformation of the technical architecture can not affect the existing business, which is the biggest principle and bottom line of the transformation. Therefore, these old systems, which play a very important role in the bank’s internal business, should be retained in a steady state in terms of the technical architecture. When we do micro service governance, we hope and assume that it’s all micro services, access, specification, governance, detection, display, and then it’s done. But when we do the project of micro service transformation,Microservice governance is only the foundation, and the communication between new and old systems is the focus。
Technology is complex, management tends to be unified. Especially in the digital transformation, the development framework, operation mode and communication protocol should be unified. In order to build a more ambitious goal, we should first unify the communication protocol. When the protocol does not get through, naturally we should do a good job in protocol conversion. Most sensitive systems are seven layer protocols, such as HTTP and RPC. Messages are often in JSON format, but the characteristics are relatively unified, which has been basically determined by the micro service framework. The protocols of steady-state systems are more complex, many of which are unique protocols, and the message formats are also different.
Complexity is more complex, and the scene changes a lot, but it’s not particularly difficult after the scene and planning are clear. There are two reasons. One is that we only consider the communication between sensitive state and steady state. In fact, the communication is not frequent, so the performance requirements will not be particularly high. Of course, if there are high performance requirements, we should try our best to avoid them in planning; The second is that we only consider the specific interfaces of the actual communication, and do the protocol translation work one by one. The average time of each interface is half a day. So where to do the translation work? The dirty work is thrown to the API gateway.
API gateway: the bearer of digital transformation
Not only in the project of digital transformation, but also in many new architectures, API gateway can be used. Of course, I want to talk about service grid. Sidecar is actually an API gateway. For example, envoy is used in istio’s solution. Here, the API gateway needs to play at least three roles:
- In the sensitive architecture, microservice gateway is needed for application aggregation to provide external services. This is the simplest gateway. To make it simple, you only need to support the configuration of routing; to make it complex, you can also add some governance, use, permission, approval and so on.
- The unified external interface of ESB, ESB (or other service bus in SOA Architecture) itself is very similar to a gateway, which integrates, transforms and communicates different protocols of all other systems. But from the service bus is usually TCP protocol, in short, it is not a comfortable protocol of micro service framework. So we still need to turn it into a sensitive system, which can access the protocol at will. This is the second role of API gateway, which is used to interface with service bus such as ESB.
- There is also an independent business system, which is neither taken over by the service bus nor transformed into a microservice, but just wants to register in the registry and exchange visits with microservices in the way of microservice communication. In the past, we strongly disapproved of using sidecar to connect the old system to the micro service framework for governance. However, we found in the project that the enterprise does have such a demand. Fortunately, the scheme is simple. The so-called sidecar is the API gateway, which is still to do a good job in protocol and message conversion, and then register it to the registry in the form of business services. In this way, after the transformation of the business system, it can better connect with the previous micro services.
So the focus and difficulty of the project is actually the construction of API gateway. Why is it the focus?The technical architecture is to standardize, the service governance is to observe in operation, and the gateway is the bridge of business communication in operation, which directly affects the access of business.
To sum up, most of the financial, securities, small and medium-sized banks have been in the key stage of digital transformation, and the real value of transformation actually lies in standardized management and concept learning. The world is changing too fast. It’s too late to learn when it’s necessary. Now we should try our best to focus on learning and adapting. So the key in the transformation: the selection of new technology, the scope of transformation, and the compatibility of stock. In this article, we have made a brief introduction, hoping to provide some ideas and reduce some worries for enterprises that are about to do digital transformation or are doing digital transformation projects. In the future, if there is an opportunity, we will make a more in-depth discussion on each part of the microservice technology architecture.