Issues to consider for a service architecture

One: Service of

The "service" mentioned here, essentially, means "RPC". Simple RPC function implementation, in fact, is very simple, is nothing more than the client initiated the call, the middle of a component (even the client itself) intercept the call information, serialized after the message to the server side, the server side received a call request after deserialization, The return response is transmitted back to the client when the actual call is initiated in detail based on the request. Such RPC is common, such as in the case of common stored procedure calls. But in a complex business environment, how to manage and collaborate with these large amounts of RPC is the most troublesome thing. Therefore, the "service" in this talk more refers to the management of RPC.

= "Serialization of Data"

The benefits of using a unified data serialization protocol for services across the environment are obvious, significantly reducing the cost of communication between service providers and service callers, while also reducing the complexity of the code for service providers to meet the requirements of different data protocols. So, the first important thing to start designing a service framework is to select a standard data serialization protocol. How to choose the right serialization protocol emphasis needs to be coordinated by three factors, from extensibility, transmission performance and industry versatility (in other words, the level of support for different technologies/languages). At present, in these three aspects are done better, is also the most widely used JSON and PROTOBUF, text-based JSON in terms of readability and flexibility, while the binary-based PROTOBUF in the transmission performance is better. And if the entire environment development of the technology stack is more unified, such as all java/.net, but also can choose to this technology more friendly serialization protocol. I prefer JSON, because in the face of the business situation, transmission performance is not a fundamental contradiction, and flexibility requirements, while the service users use a variety of technologies.

Second: The challenge of traditional application development

Challenge one: High cost of research and development
2008 I came to Beijing to participate in a TOP3 project at that time, and party A is China Mobile. At that time the company had just done Java-class software, there is no service framework and middleware, the only external framework. What we want to do is a background message class system with very few front-end interfaces. The Division of labor and collaboration is done entirely by hand and without consideration for interaction, at a time when the code duplication rate is high, the demand changes are difficult, and the new business is not able to meet the challenges of fast online and agile delivery.

Challenge two: Low efficiency of operation and maintenance
For the operation of the experience is more profound is 07 I in the Neusoft to do an ERP system. Key issues include:

Testing and deployment costs are high: the business runs in a process, so any program changes in the system need to be re-tested and deployed across the system.
Poor scalability: Horizontal scaling can only be extended based on the entire system and cannot be scaled on demand for a single function module.
Poor reliability: An application bug, such as a dead loop, oom, can cause the entire process to go down and affect other applications that are in use.
Code maintenance costs High: The local code in the continuous iteration and change, and finally formed a vertical functional island, only the original developers understand the interface call relationship and functional requirements, the new join or the team other people difficult to understand and maintain the code.
Dependencies cannot be managed effectively: Inter-service dependencies become confusing, and even confusing which application to start before, architects cannot fully describe the application's architectural relationships.

Solving countermeasures
To solve the above problem, the main first measure we take is split, including horizontal split and vertical split. After the demolition we will find that we have formed a pool of resources in the center of a variety of separate clusters by business domain. When we develop the application, we will find that no matter how the need to change, in fact, it is easy to change is about 20% of the function, in fact, we have to isolate the changes to control the change. The practice is to extract and identify our core, and our public to precipitate into the lower layers to form a public independent capacity layer, and then gradually form a stable service capability center and then sink. The front end includes a change in the middle layer to abstract it out and do it as a consumer. After the separation of the front and back end, we can effectively manage. The ability to control changes in requirements after a change, including testing and the entire cost, can actually be effectively controlled.

Three: Service splitting and grouping

The traditional SOA concept refers to the integration of different application systems into each other through large-grained services. Today's service architecture has been freed from this concept, more about the system's internal module level or even the functional level of service mode. This means that the granularity of service implementations is even smaller. This, of course, provides greater flexibility in the implementation of applications and services, and the service delivery cycle is greatly shortened. But the problem with such fine-grained split services is that the number of services required to access the feature is multiplied exponentially. As shown in: A customer to place the order of the functional implementation needs to be accessed separately: Customer Information Services, product Category services, inventory services, order Management services.
Figure 1:

This will significantly increase the complexity of the feature implementation. To solve this problem, we can only re-use the "middle tier law" that is always effective: any computer problem can be solved by adding a layer in the middle. We can combine the corresponding service groups to provide a new service, such as the above example, we can be grouped in the following ways:

Figure 2:

The service provider registers its service with the registry, and the consumer subscribes to the message, and then caches a provider's information locally. So every time the interaction, only the local memory can be, do not need to strongly rely on this registry, in fact, the service center relies on a weak dependency.

4:0 intrusion

In our actual design process, it is hoped that this service framework or service to the upper application of the intrusion as small as possible, but the hundred Baize intrusion can not be done. By configuring and expanding, consuming, and publishing, the configuration itself is an intrusion and part of the code. But the advantage of this is that we change a rep better than to compile it. It means that we try to keep the API of the service framework open to the top, while the open ones are some of the features and configurations, or they can be annotated. In this way, the future of our service framework, regardless of the bottom of what kind of integration and restructuring, in fact, we do not have to worry about.

Five: The future direction of evolution

1: Micro-service architecture
The first major evolution was the microservices, which had been discussed for two years. My experience is that first it is a separation of architectures, and there must be no standard in the foreseeable future. The fundamental thing is that in the process of evolution, we will find some new challenges when the service is over, including the need for agile delivery, more granular isolation and interaction. If we do not have a good set of tools and processes, to be able to take care of the micro-services, to do MicroServices will still face a lot of problems. Including the division of some teams, like the Amazon team, to build a full-stack squad, in fact, is about four to five people scale. This person is responsible for the micro services he belongs to from the development, testing, packaging, deployment, on-line, run, repair by the team unified responsibility. With the traditional research and development is research and development, testing is testing, operation and maintenance is operational, division of labor or there is a difference. In fact, the team can accept, or the effectiveness of the whole team practice, but also to determine the results of your entire implementation.

So one of my judgments about microservices is that, if your service has been implemented for many years, you've come to the point where you need to evolve from a micro-service. If you do not have such an infrastructure to push, the effect will certainly be very poor.

2: Docker-based deployment microservices
This year is a very popular word, that is, microservices are inherently deployed in Docker. Why is it? Because after so many things, first of all we must consider the deployment is fast, I once packaged the deployment, and I go to deploy 10 VMS, the speed is not the same, so that its cost will make the application feel I can not really take apart the independent deployment. With Docker, such as the second level and creation of Docker, and the isolation, use, and consumption of resources, these features determine a microservices or a number of microservices running in a Docker container, which is a very good deployment strategy.

Let's take a look at the features of Docker's service, in addition to the high density, rapid deployment of microservices, there is actually an advantage, such as a consistent environment, to avoid the reliance on a particular cloud infrastructure provider, including its dependence, and so on, we can enjoy.

3: Micro-services on the cloud
After the cloud has a problem, my original microservices including my original service will also be migrated to the cloud, so it will enjoy another feature, such as elastic scaling on the cloud and flexible and rapid scheduling of resources. After migrating to the cloud, my service could have been automatically discovered. With this elastic scaling, I combine service performance KPI data plus my threshold value, I can achieve automated operations, when the expansion of the time will not require manual intervention, I need to do it myself.

There is also a virtual machine, with a virtual machine we found that the isolation of resources can be done better, VMS can be very small across. This time I can use its fault isolation for finer-grained isolation. For example, we used to worry about a micro-service, in fact, do a fault isolation, in fact, will still be down, this time can be isolated by the VM, VM-Level fault isolation. With the cloud, to provide a lot of features, if it can be combined with our existing service framework, will bring a lot of value, the value of operation and maintenance can actually help us to many of the previous manual operations, can be through the cloud after the service to achieve automated operations, of course, there are many and the combination of clouds, This is an evolutionary process that needs to be slow.

Issues to consider for a service architecture