Shulou(Shulou.com)06/02 Report--

Author | Zhang Yuchen (Tong Zhao) Aliyun delivery expert

Guide: nowadays, almost everything can not be done without software. when you are driving, when you step on the throttle, in fact, the computer in the car calculates the output power through force sensing and so on, and finally controls the throttle. You never thought it would be an engineer's code.

When we talk about architecture, what exactly are we talking about?

Object-oriented programming? Functional formula? Modular design? Micro services? These words seem to have something to do with the buzzword of architecture. Indeed, our field is full of words that are difficult to understand. Some of these words have lost their context when translated from English to Chinese, and the meaning is completely distorted with the change of context, such as engine, framework, architecture, application, system. It's true that people more or less agree on these words and use them to communicate at work, which sometimes means "what we all know", but when I want to talk deeply about architecture or software architecture, I do have to ask myself this question, what are we talking about?

In fact, the scope of the word architecture is relatively fixed according to the context. Architectural architecture refers to the building structure, overall design, composition, and so on, while these high-level designs often do not need to have a comprehensive understanding of the bottom layer, just like when using RestTemplate for WebService calls, we do not care that the socket is connected in four layers, because the details are hidden.

However, there is a great difference between architecture and software architecture. The problem lies in the word "software". According to the definition of software, ware refers to the same thing as a product, while soft emphasizes variability, which corresponds to hardware. We hope that the "software" can make rapid changes and should be able to respond quickly to the needs of Party An or customers, so the software architecture must not be like the building architecture, once the building is completed, the cost of modification is extremely high. and the software should take the corresponding direction and give full play to the characteristics of easy modification.

"most of today's software is very much like the pyramids of Egypt, where thousands of bricks are built between each other, lacking structural integrity and done only by brute force and thousands of slaves." -- Alan Kay.

The author believes that although I agree with the meaning of this sentence, in fact, the pyramids, as the mausoleum of emperors, have complete design logic, and with the iteration of several pyramids and gradually complete construction management, the late pyramids are very outstanding architectural representatives and have been the tallest man-made buildings on earth for thousands of years. There is still controversy about whether the pyramids were built by slaves. (picture from Isabella Juskov á @ Unsplash).

As engineers, on the one hand, we pay attention to the capability and behavior of software products, which is often the starting point of a project, on the other hand, we need to pay attention to the architecture design of software. because we want to design a flexible, easy-to-maintain, high-performance, high-availability system, we want the system to evolve rather than be knocked down and redone in the future. So, to correct our vision, when we are determined to design a good architecture, we need to make it clear that architecture often determines the non-functional requirements of the software. These non-functional requirements are:

1. Easy to develop

We hope that engineers can start research and development as soon as they join the team, we hope that the code is easy to read and understand, and that the development environment is simple and unified enough, so you can recall the pain of the learning context when you enter the project. When we started using docker-assisted development, the then architect made a requirement that docker could be used to launch the local test environment with a single command, and all microservices had to do this. After the painful transformation is completed, students who enter the project three years later only need to install docker and run a. / run-dev.sh in ternimal to get a local environment with complete dependency.

two。 Easy to deploy

If the deployment cost of the system is very high, then the use value will not be very high. Many of our enterprises have systems that do not dare to move, dare not change, or dare not stop. There seems to be no other way but to pray that it does not hang up. Or many enterprises have adopted the advanced choreography system like K8s, but when the application is deployed and launched, it still changes every Thursday. Modern distribution methods such as AB, Canary and Grayscale cannot be adopted because the renovation cost is too high, or there are not enough automated tests to ensure the security of the changes, let alone release to CI\ CD.

3. Easy to operate and maintain

The original intention of DevOps is to establish a culture of shortening the distance between operation and maintenance and R & D, so as to make it easier to deal with problems. We hope that people can focus on products rather than limit their own types of work. This is not to expect students of operation and maintenance to become Java experts and quickly conduct heap analysis to find problems. We emphasize the closed-loop ability of operation and maintenance. At the software product level, we also hope that the product is independent, autonomous, can be deployed independently, can scale horizontally, and has complete observability. after all, today's hardware cost is often far less than manpower.

4. Maintenance cost

With the passage of time, it will become more and more difficult to add new features to the software, and the longer the project runs, it will fall into the agony of rewriting or refactoring. Often the risk is that changing the code will increase the risk of destroying existing functions, and the technical debt will become more and more difficult to repay, even if we rewrite some features and modules, it is difficult to determine whether all the functions are really covered. In short, don't break anything is indeed very difficult to do.

5. Evolution ability

And most importantly, the ability to evolve. Good architecture should keep the system in a state of easy evolution and the ability to change tires for speeding cars without being kidnapped by frames, underlying databases, operating systems, or other things, but it's too hard to do. Indeed, in the technical selection of the project, there is a tendency because of the characteristics of a certain database, but in the upper design, we must ensure that we do not rely on the characteristics of the database and put the use of these features in the underlying details. We also need to consider, without using the Dependency Injection provided by Spring, how should we organize our beans, and also consider whether the front end of the system in the future is web or mobile or both?

To quote the primitive of Robert C. Martin (Uncle Bob), "Software products have two values: the value of realizing functions on the one hand and the value of architecture on the other, and the value of architecture may be more important because it represents the characteristics of software soft."

There are too few examples in this book, and there is a lack of suggestions for reconstruction or improvement of the existing popular framework, which is a bit metaphysical, but at the methodological level, the author still thinks it is worth reading.

Robert C. Martin's attitude towards the database (especially RDBMS) is worth discussing. First of all, he thinks that the database is a detail, which should be decoupled from the business in the architecture. He emphasizes that the business code is independent of the database. At the same time, when our code does calculations, tables are often not an ideal data structure, for example, some scenarios will use trees, DAG, and so on. Recall that when you need to store a tree in a database, how do you do it?

Microservice is a software architecture, don't extend it.

According to our previous discussion, the use of micro-services in the back-end system will not affect its functional value, and in essence, the difference between micro-services and single applications will not be expressed in terms of function. many students who are not doing well in micro-services often say: this thing is written with a single unit. Indeed, this side also confirms that micro-service is only a kind of software architecture, not something magical, and that a business requirement does not have to be completed using micro-service. We take a fancy to micro-service, but also focus on the advantages of architecture, that is, those non-functional requirements. Some people use pattern to describe it, others say that it is basically the same thing as SOA, but with different granularity, so let's not believe that there is a panacea in the first place, and don't expect any technology to replace Oracle in an instant.

As students developing "enterprise back-end applications", we often face a lot of troubles on non-business requirements: sometimes we need to support mobile, mobile web and desktop clients at the same time; sometimes we need to support different protocols such as JSON or XML;, and sometimes we need to use different middleware to deliver messages. Or in R & D, we know that there is a place that is not well written, and we want to make up-to-date lessons in the future; we want to try the latest technology, but the cost is too high; the system cannot be expanded, or the cost is very high; the system is too complex to run locally, resulting in extremely low efficiency. These troubles are the main driving force for the adoption of micro-services, and back to our discussion of software architecture, what we hope is to reduce the cost of changes between components through enough loosely coupled independent services, that is to say, the ability to update and send notifications today will not affect users' view of shopping carts, nor will developers wait three days to go online after half a day of changes.

But there is no free lunch in the world, although we know that microservices have many good features, such as component as a service, loose coupling, independent deployment, business orientation, high maintainability, high scalability, and so on. We don't want to discuss its benefits here, let's consider the input cost first. Suppose that each of our students has fully learned all the knowledge of microservices, is very familiar with the frameworks and products on the market, and is ready to start. After dismantling several services, we will find that there are not enough automation means to test, compile, deploy and monitor manually, which will obviously reduce the experience if there is no optimized deployment strategy. All the services are launched on a certain release date, which is even more of a disaster.

With the expansion of the scale, the cost of code changes for single applications will become more and more expensive. In many cases, there are misunderstandings in our micro-service architecture practice. We always think that traffic goes directly to a certain service after passing through a certain gateway, ignoring the scenario of calling between services. The ideal micro-service architecture should be a network, and each node is an independent and autonomous service.

Some scenarios that were previously easy to do with a single unit will be more difficult in a distributed environment. For example, we can support consistency through database transactions provided by RDBMS, but if the order service and price service are separated, it is necessary to conduct distributed transactions to ensure consistency (often the final consistency), and the cost and difficulty of distributed transactions need not be discussed. In a single environment, we can easily use aspects for permission verification, while in the scenario of micro-services, it is difficult to control the mutual invocation between services.

Splitting services or demarcating service boundaries is another difficult thing to do. Perhaps the most popular theory is to divide services according to DDD. Natural domains or domain seem to correspond to a service, because sufficient boundary contexts (bounded context) can maintain the independence of services, so that their details are hidden within boundaries, which sounds like a good idea. But the reality is very cruel, there are not a few examples of using DDD to mechanically copy software development, and successful examples are difficult to copy.

Although I often use business areas for service division in practice, I don't think this is the practice of DDD. There is no need to specify how many services there are in as many domain as there are, and there is no need to specify whether sub domain can serve independently. Instead of working on a top-level design package, I believe in the power of evolution. If you really need to split a service, enough infrastructure and automation tools should allow you to do it at a low cost. Instead of drawing all the architecture diagrams in the first place. Like all reforms, revolutionaries often do not succeed in one step, but accumulate gradually. So using microservices, when you can afford (only you can afford it), also means that you can afford failure, the technology world does not happen overnight, all in is very dangerous.

The microservice transformation of the Guardian website (Guardian) is a good example. The core of the website is still a huge unit, but the new functions are implemented through microservices, which call the API provided by the monomer to complete the function. For frequent marketing activities (such as the dedicated section of a sports competition), this approach can quickly achieve activity pages and functions, complete business requirements, and delete or discard them at the end of the event. In my previous project, I also Strangler Pattern a huge old JBoss application through the same amount of replacement and refactoring.

Mark Cerny, the chief designer of PlayStation, mentioned in the technology sharing of PS5's new console this year that game consoles need to balance evolution and revolution (balance the evolution and revolution). We don't want to lose the accumulation of developers over the years. We also hope that you can use more advanced technologies when reusing past successful experiences.

Everybody loves / hates Spring Cloud.

It seems that in the Java world, Spring Cloud seems to be the best solution for micro-services. even on the resumes of many students, Spring Cloud can almost be equated with micro-services. More than once, someone told me that the company's technology stack is not Java, so it's hard not to do micro-services, it's not that I don't have the spirit of learning and adventurous spirit and so on.

Unfortunately, for software architecture, there are no specific programming languages, and there are many versions of design patterns. In the final analysis, it is Spring Cloud's family bucket strategy that is more attractive, and nothing is more attractive than the magical sub-era architecture that you can have with a few jar.

Undeniably, when I was learning Spring Cloud, I was amazed at its integrity. Almost all the common micro-service requirements have sufficient complete solutions, while most of the solutions are done at the application layer and have good adaptability, such as eurake registration discovery, zuul gateway and routing, config service, hystrix circuit breaker, etc., through a unified programming paradigm (annotation-based injection and configuration) There are plenty of functional choices (there are even two options for common functions), as well as a better way of integration.

The former has the successful experience of Netflix, and then with the wave of micro-services, coupled with a large enough Java community, it can be said to be the king of the king. But Spring Cloud is not without weaknesses, on the contrary, these functional designs have differences with the subsequent containerization tide. So far, the integration of Spring Cloud and Kubernetes is a hot topic. Here we start to talk about its shortcomings or limitations (limitation).

1. Intrusive and verbal kidnapping

This is probably the biggest problem. Basically, we can only use Java as the research and development language, which is also controversial in China, because both architects and entry-level programmers need to try new technology stacks to store or adopt new functions, and for example, it is difficult to use self-made client to achieve ribbon load balancing, but it is also difficult to do this without Java, not that Java is not good enough. Instead, we should have more choices for the future, and programming languages should not be a limitation for a technology company. Who doesn't want to learn a little golang or rust or scala in this day and age?

Other services such as SSO and Config Service are also too holistic, and if you want to make some adaptation, you have to make a lot of changes (fortunately, open source). We are worried that this situation will be pushed to a new level as the framework grows old, and Ruby on Rails may be a warning. Intrusiveness is another issue. Remember the rules of practice that we advocated when we discussed software architecture? Try not to let the top-level design rely on the underlying framework or some details, but the direct references to annotation and jar on the screen undoubtedly tell us that it is very difficult to get rid of them.

two。 The problem of cloud native fusion

For cloud native, both CNCF and Pivotal (VMWare) emphasize containerization, micro-services, cloud-oriented environment, and so on. CNCF begins to grow around Kubernetes, and with the popularity of this advanced container choreography technology, people gradually find that there is still a lot of functional overlap between K8s and Spring Cloud. Although there is no overlap between K8s and IaaS, how many manufacturers are promoting pure IaaS now? Since there is functional overlap, there is a trade-off, and considering the family bucket attribute of Spring Cloud, this divergence has not been well resolved.

3. Centralized resources

Both Config and Eureka are single points of aggregation, even if they have clusters to achieve nearly 100% reliability, but in logical architecture, all microservices depend on them. The coupling of these centralized resources is very strong, and they will always exist in your production environment until the last system that uses them is offline. We need to avoid using shared instances and resources in the architecture, and an application will not crash because it cannot write logs, nor should it fail to start because there is no eureka locally.

4. Fear of platform binding

Admittedly, it is good to solve service registration discovery and load balancing within the process, which represents the best platform independence, but other capabilities of the platform are also difficult to enjoy. Binding K8s seems to be a better choice, because it is more flexible than Spring Cloud, and it can not be bound by the basic cloud platform, but it is also more difficult to master and operate. Of course, I do not think that K8s must be the choice of micro-services, as a container choreography platform, it can do more things (such as running databases, middleware, etc.), and running micro-service applications is just one of them.

5. The landing ability of methodology

Halfway through 2020, technically speaking, Serverless has matured, Kubernetes has become more mature, and has become a de facto standard. But most of the time, our methodology and architecture design can not keep up with the technological development, many students may still go through the weekly release day, many students have no way to improve the old technology in the team, many students' Jenkins is still in the packaging stage, many students still do not install docker on the machine, most of the time it is not the framework or platform problem, but the methodology is still in the past.

6. Maintain evolution

Applications should also practice the principle of opening and closing, and being open to extension gives us more choices in the future. Microservices are a good opportunity for us to truly evolve our architecture without paying too much cost. when we need a component-based system, the key feature of the component is that it can be replaced or upgraded independently. We can replace and restructure without affecting other parts, which is obviously lower than rewriting by abandoning the old giant framework.

With the right attitude and tools, we can control changes faster and more frequently, we can radically choose new technology stacks, or we can merge two services that are too tightly coupled. With the continuous aggregation and extraction of services, you will find that the logical structure of the system will become clearer and clearer, and if you modify it, you will be more confident. We can use different storage technologies for each service, and we can use OSS to process files instead of continuing to cram pictures and videos into Oracle.

The solution and problem of Istio, and what is missing in Mesh?

Although the opening lightning strike was full of troughs, it did not reduce the confidence of the community in Istio. On the contrary, it gradually found that this big change made Istio a little easier to use and could be used in production without paying too much. Of course, beautiful words are always easy to say.

Service Mesh was a fledgling concept in 2017, and now it has become the choice of the future in the field of micro-services, but unfortunately, only Istio is mature enough to represent this technology. Of course, I have had the honor to practice similar Sidecar for reverse proxy, log collection, performance monitoring, health check and other functions, but there is still a big gap from Mesh's vision.

Today, we do not want to expand the advantages of Service Mesh or Istio, the solutions outside the process can ensure the flexibility of the system, while traffic control, service governance, end-to-end transmission security, current restriction, discovery registration, etc., we hope that engineers can focus on the business, achieve architectural flexibility, focus on real value, and configure the rest. So I think that's why Serverless is infinitely bullish. If we want delegate control of infrastructure, why do we need to care about containers? The Istio + K8s solution is good enough, at least our team is learning carefully. We still have a lot of problems to solve before providing best practices to our customers. Here are some representative ones:

1. Elasticity and self-recovery problem

It is a common requirement to trigger auto scaling using system metrics, parameters, etc. Here are we using cloud monitoring? Or do you set up your own set? I have always tended to decouple data from usage and use pub sub patterns to solve problems, such as too high CPU may trigger multiple behaviors: trigger alerts, trigger elastic rules, and display on dashboard. We can add pod to share the service pressure, or launch a new pod to complete self-recovery after a pod exits abnormally. This series of actions also need to be solved by ourselves.

two。 Monitoring and observability

There are many practices on observability such as logs and alarms. The only concern is that the APM function of ARMS or Newrelic has not been practiced on the target platform. We hope to see the real-time performance of each service clearly. At present, this part is still lack of consideration and design.

3. Practice of current restriction and demotion

The flow control ability of Istio is very powerful, how to take the common governance operation of service degradation and current limit, it is also necessary to sum up the practical experience. Avoiding streaming errors (cascade failure) is also common in the field of microservices, and it is necessary to avoid fault contagion.

4. Multiple automated deployment

Blue-green, grayscale, canaries, these various deployment methods also need to land, we may write some small scripts such as deployment util, deployment methods need to communicate with CICD. A deployment tool, a configuration file, and an CICD make up how a single application will be deployed in the future.

5. ABAC and OPA

We are very optimistic about attribute-based permission control and the customizability of OPA, and sidecar can solve the problem of permission verification outside the process, which is really worth trying. Just learn how golang can be used to customize OPA.

6. Saga and compensation events

Distributed transaction is a big pit in micro-service practice. I have written similar articles before. Most of my project experience is to put transactions in a single service, and I have never had the opportunity to write a real online store system myself. Compensating events is also a common ultimate consistency scheme, but ensuring consistency is undoubtedly a great challenge.

7. High availability and chaos Engineering

It should not be difficult to achieve high availability of applications based on K8s. The natural advantage of containers is that they are easy to start and manage. If killing pod randomly does not affect system availability, it can be regarded as achieving a capability similar to SLB + ECS + ASG. The real danger is other non-business pod, such as various supervisor of istio.

In the practice of micro-services, what an architect thinks about is far more than just implementing the business, but once the road is paved, the following development and iteration will be more smooth.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.