The story is pure fiction, if there is a similar, please take a seat!
Da Li is the architect of A company. He is leading the architecture of an online taxi-hailing software. There are several teams working together to develop it, and he has been busy for several months.
But Da Li is a little annoyed recently, because the taxi-hailing software he leads has a lot of problems, the progress is not smooth. His team struggled to keep up with new features introduced by rival Company D, while dealing with internal problems. Feeling very tired, he decided to talk to Lao Zhang, the company’s technical director.
As soon as he walked into Old Zhang’s office, Li came straight to the point and said: “Mr. Zhang, our current development speed is difficult to keep up with the pace of our competitors. Wanted to talk to you about what we could do to speed things up?”
“Ok, can you show us our current structure first?” Zhang replied.
So, Big Li showed Lao Zhang the following architecture diagram:
Figure 1 — Taxi software architecture of A Company ▲
Lao Zhang looked at it carefully and said, “At present, our software architecture has separated data storage, and moved the computing module and storage module to jd Zhaopin cloud, and replaced physical machines with virtual machines. Our cell can also scale horizontally to handle peak traffic, and the architecture is already flexible, so what’s the problem now?”
“We are now facing a lot of problems, I may be most impressed by the following categories:
1. Release difficulty: Our cell and storage required six teams in three locations to work together, so each release was a difficult task. Senior management is required to coordinate the release plan, and you were in charge of the planning for the last release.
A small problem with one module can delay the entire project, but in reality every module has problems, so it is often necessary to prepare multiple rounds of regression testing to ensure that all modules have no major problems. Last time, the code of the billing module that Xiao Wang finally merged in actually affected the customer management module, and then everyone worked overtime to test and fix the problem, but the delivery was still two days late.
If any module has a problem, the entire application needs to be debugged together, and then released online. Each new release is difficult, leading to a long wait for fixes for minor issues.
2. Dependency between modules: Many modules run in a virtual machine, and the dependency between them is complex. So the order in which each module is started is critical and must be carefully arranged, and every module change can cause the order to change. Problems with boot order occur almost every time a new version is released.
Again, because each module is running in the same virtual machine, the priority of the thread they are running on becomes very sensitive and needs to be set very carefully. Otherwise, in the case of a large number of concurrent requests, CPU resources are occupied between modules. As a result, some modules cannot be processed by CPU resources. Teams spent a lot of time testing and prioritizing individual threads in order to fine-tune thread priorities, but still couldn’t achieve the desired results in all cases.
4. Difficulty in capacity expansion: In the case of large concurrency, some processing units may need to be expanded. All modules must be replicated on the expanded machine. If any module is faulty during expansion, expansion fails. Expansion of modules that are not needed is wasteful and increases unnecessary risk.
Data of all modules resides on the same udSN, which makes the relationship between compute nodes and UDSns complicated and difficult to manage.
Five, difficult to maintain: because the whole system has become very large and complex, the relationship of each module is intricate. Almost no one knows all the parts of the system, so every change (new feature or bug fix) may not be discovered until the very end, adding to the delay. Any further departures of key personnel would exacerbate the situation. The resignation of Mr. Jin last time is a strong proof that although the replacement is still familiar with the module he is in charge of, the relationship with other modules is very complicated. As a result, one bug is fixed but two new bugs are introduced.
In summary, I think we have to change our architecture to make it simpler, more independent between modules, easier to maintain, distribute, and expand.”
“I am also aware of the problems you mentioned. Recently, I have been studying microservice architecture and various microservice platforms.” Zhang nodded in agreement. “According to my preliminary research, if you want to solve those problems, you need to consider evolving to a microservice architecture. Microservices should solve most of our problems and increase our productivity. I recommend an article that you can study first and we can discuss it in detail later.”
Micro-service Literacy: The Ideal and Reality of Micro-Service
Hearing Lao Zhang’s answer, Da Li turned to joy and said, “That’s great! I’ll go back and do some research. I’ll talk to you in a few days.”
A week later, Mr. Li found Mr. Zhang again: “Mr. Zhang, I have carefully studied the theory and framework of micro-service. As I understand it, if our architecture morphed into this microservices architecture map, it would pretty much solve the problem we’re facing.”
Big Li said as he showed Lao Zhang his microservice architecture diagram:
Figure 2 — Microservices Architecture
“As you can see from the architecture diagram, basically all the original modules have become loosely coupled microservices that can be independently deployed, distributed, and scaled up. We can solve all the problems of release difficulty, expansion difficulty, module CPU resource competition and module dependency. This way we can release new versions of each microservice independently, making the release of new features and bug fixes much faster.” “Big Li said excitedly, her eyes glistening.
“At the same time, the process management module is no longer required for independent deployment, and microservices do not have to share infrastructure modules and can choose technologies based on their own needs. And because services are now well defined and each microservice is responsible for relatively simple and cohesive functions, developers can easily understand the internal logic of a single module, so maintenance problems can be easily solved.” Big Li went on.
Lao Zhang had a satisfied smile on his face. “That looks like all our problems have been solved. In addition, our company has started using Agile development, built a Scrum team, and we have Devops experience. So each team in the three locations can become a separate Scrum team, responsible for independent microservices, so that the problem of people working together can be solved. Can we start microservitization right away?”
Big Li frowned again, difficult to say: “Zhang, although the micro service is very good, we must evolve in this direction. But microservices also pose great challenges for us.”
“Well, there’s certainly no such thing as a free lunch.” Lao Zhang then asked, “Tell me, what are our main challenges?”
“First of all, we need to split the existing application into multiple micro services. It’s our business, it’s critical, and we need to do it ourselves. But there are a lot of things in the microservices architecture itself, such as this service registry discovery diagram. If we adopt the springcloud architecture, we will need to deploy and maintain the registry ourselves after integration. Registry clusters must also be highly available. If we were to deploy and maintain the registry cluster ourselves, we would be at a disadvantage as we would not have eureka or Consul’s expertise and would need more engineers for deployment and later operations. This will increase our costs significantly and our organizational structure will become more complex.”
Figure 3 — Service discovery
“Are there any other questions about the microservices infrastructure besides the registry?” Lao zhang asked.
Big Li thought for a moment and answered, “There are still a lot of problems. For example, after we split into micro services, the call analysis between many services is very needed. So we need to invoke chain analysis, which leaves us with the same problem. For example, if we use Jaeger for call chain analysis, as this call chain diagram shows, we also need to maintain complex Jaeger clusters and be highly available.”
Figure 4 — Call Chain (from jaeger website) ▲
Da Li opened another architecture diagram of the micro-service gateway and pointed it out to Lao Zhang: “The other one is the micro-service gateway. I discussed with my team that microservitization should be done step by step. We will first microservize the unimportant services and evolve step by step. As we continue to learn, we will microservize the important modules. It’s less risky. So we need a microservice gateway to expose microservified services to non-microservified applications. For example, we can first microservize the notification service, while other core logic remains unchanged. We can call the microservized notification service through the microservice gateway. Then we need to maintain the microservices gateway cluster again.”
Figure 5 — Microservices Gateway ▲
“In addition, we also need to configure the central cluster for configuration management. We also need to quickly deploy our application to a virtual machine. You need a console for application deployment, configuration, and service governance such as authentication and routing.” David went on to add.
After listening to Big Li’s introduction, Lao Zhang fell into a deep thought: “What you said is very right. It seems that micro-servitization still brings us great challenges. For example, microservices gateways do need to be considered as an evolving architecture to ensure the stability of services. It’s not realistic in the short term to do all of this by ourselves, and it’s more important that we focus on our own services rather than microservices infrastructure.”
“Are there any microservices out there? Can solve these problems for us while we focus on our own business?” Big lee asked.
“This is a very good question, I heard jd Zhilian cloud launched a JDSF micro-service platform, you can research. I looked around and felt it would fit our microservices infrastructure needs.” As Zhang suggested, he opened the JDSF product page of JD Zhilian Cloud and showed it to Da Li:
Scan code to understand JD Zhilian cloud JDSF
Big Li eyes a bright: “good, I this go to study.”
Two days later, Mr. Li rushed to Mr. Zhang’s office: “Mr. Zhang, I have carefully studied jd Zhilian cloud JDSF, and this platform can completely solve our current requirements for micro-service infrastructure. I have summarized the following points:
JDSF has a registry and configuration center/call chain analysis/and micro-service gateway, all of which are deployed and maintained by JD Zhilian cloud to ensure high availability. JDSF supports SpringCloud, Dubbo, and JSF, and we can choose any of them by integrating the JDSF SDK. We can upload jar/ WAR packages and then JDSF can help us deploy on virtual machines and support rolling deployment. Configuration management and service governance (such as authentication and routing) can be easily managed on the microservices console. As this routing diagram shows, we can do grayscale publishing.
Figure 6 — Routing ▲
With this solution, we can easily transform our applications using microservices architecture.”
“Then our entire architecture will evolve to this final architecture, where the grey parts are all things that JD Zhin.com JDSF did for us. We just need to focus on our business logic. With this architecture in place, we can quickly release new features and focus on competing with D in the marketplace.”
Figure 7 — Final structure of A Company ▲
“Great! I learned from my friends in JINGdong that their internal collaborative office platform is also using this micro-service platform, and there are hundreds of thousands of employees in Jingdong using this collaborative office software. I believe we will be able to integrate soon.” Lao Zhang immediately made a decision and arranged For Li to immediately start micro-service transformation together with JD Zhilian Cloud.
Does your company face the same problems as Big Li and Old Zhang? When a very complex application needs to respond quickly to the market and have dynamic capacity for expansion, but the application itself faces problems such as rapid release and difficult maintenance, and thus cannot meet the demand, microservice architecture should be considered to solve the problem.
However, it is important to note that while microservices architecture can solve problems, it also introduces complexity at the architectural level and requires the support of microservices infrastructure, which also presents a huge challenge for enterprise architecture.
Jd Zhilian CLOUD JDSF micro-service platform is to meet the simplicity and feasibility of micro-service, and provides basic components, service governance, application management and other functions, which can greatly simplify the transformation of enterprise micro-service and avoid risks in the transformation of architecture. If you are also interested in the JDSF micro-service platform, please click [read article] to try it out.