Monolithic application
Another concept opposite to microservices is the traditional "monolithic application" (Monolithic application), which contains all the required services. Moreover, each service function module has a strong coupling, that is, it depends on each other, which is difficult to split and expand.
Everyone in this room has written a single program. Let me give you a chestnut. At the beginning of writing code, you write a helloworld program. It is a single program. A program contains all the functions, although the helloworld function is very simple.
Advantages of monolithic applications
-
The development is simple, and the functions are all in a single program, which is convenient for software design and development planning.
-
Easy to deploy, single program does not exist in a complex deployment environment of distributed clusters, which reduces the difficulty of deployment.
-
It is easy to test, there is no complicated service call relationship, and it is called internally to facilitate testing.
Disadvantages of monolithic applications
The shortcomings of the monolithic program are not particularly obvious at the beginning, the project has less demand at the beginning, the business logic is simple, and writing code is cool for a while, and always cool. The nightmare starts with the iterative update of the business and the increasingly large system. The early days are gone, and replaced by the endless pain of software maintenance and iterative updates.
Monolithic architecture
Since a monolithic application is like a large container, many services are placed in it, and they are all inseparable, which leads to an application as a unit when it is expanded.
When the load of a business module is too high, the service cannot be expanded separately, and the entire application must be expanded (it is so overbearing), which may result in additional waste of resources.
In addition, due to the closeness and interdependence of services between monolithic applications, it will be difficult to test and upgrade, and the development curve may increase significantly in the later stage, making development difficult. In contrast, "microservice architecture" can solve this problem.
Microservice
Microservices are small and autonomous services that work together.
❝In 2014, Martin Fowler and James Lewis jointly proposed the concept of microservices, which defined that microservices are small services composed of a single application. They have their own itinerary and lightweight processing. The services are designed according to business functions and are fully automated. It is deployed in a way to communicate with other services using HTTP API. At the same time, the service will use the smallest scale of centralized management (such as Docker) capabilities, and the service can be implemented with different programming languages and components such as databases. "Wikipedia"
❞
For example
Or take the previous helloworld program to give a chestnut, imagine you are the CTO of helloworld company (the boss still lacks people? can write code), suppose your company’s helloworld business spreads all over the world, and you need to write helloworld versions in different languages. Separately output English, Japanese, French, Russian... Now there are more than 6000 languages in the world (strange knowledge has increased).
Some people will say that this is not easy. I switch casewill finish it with sentences. Classmates, don't be true. I will give you an example. The business in reality is much more complicated than helloworld. Well, let's tentatively think that outputting by language is a huge and complex task. At this time, the microservice architecture can be used. The architecture diagram is as follows:
Microservices and SOA
"Service Oriented Architecture" SOA (Service-Oriented Architecture) sounds a lot like services and micro, but SOA early models were used bus, this bus model is a technology stack with strong bindings, such as: J2EE. This has caused many companies’ legacy systems to be difficult to connect. The switching time is too long, the cost is too high, and it takes some time for the stability of the new system to converge. It SOA looks beautiful in the end , but it has become an enterprise-level luxury product, and small and medium-sized companies are daunting. .
In addition, SOAmany problems will be encountered during implementation , such as the choice of communication protocol (such as SOAP), how to choose third-party middleware, how to determine service granularity, etc. There are also some guiding principles on how to divide the system, but there are many of them. All are wrong. SOAIt doesn't tell you how to divide monolithic applications into microservices, so SOAyou will encounter many problems during implementation .
These problems are well solved in the microservice framework. You can think of the microservice architecture as SOAa specific method.
Microservice architecture
In view of the above-mentioned shortcomings of "monolithic applications", a single application is divided into various small, interconnected microservices. A microservice completes a relatively single function and maintains independent reconciliation between each other. Coupling, this is the microservice architecture.
Advantages of microservices
Compared with monolithic services, microservices have many advantages. Here are a few main advantages
Technology heterogeneity
The internal development technology of different services can be inconsistent. You can use java to develop helloworld service A and golang to develop helloworld service B. Everyone no longer has to argue over which language is the best language in the world.
Choose the most suitable technology for different services. Different parts of the system can also use different storage technologies. For example, A service can choose redis storage, B service you can choose to use MySQL storage, this is all allowed, your service You decide.
Isolation
The unavailability of one service will not cause another service to be paralyzed, because each service is an independent and autonomous system. This is impossible in a monolithic application. A module in the monolithic application is paralyzed, which will inevitably lead to the unavailability of the entire system. Of course, the monolithic program can also deploy the same program on different machines to achieve backup. However, there is also the problem of waste of resources mentioned above.
Scalability
If a huge single service has a performance bottleneck, it can only expand the software as a whole. It may only be a small module that affects the performance, and we have to pay the price of upgrading the entire application. This has been improved in the microservice architecture. You can expand and upgrade only those services that affect performance, and the effect of prescribing the right medicine is very good.
Simplify deployment
If your service is a large single service with millions of lines of code, even if you modify a few lines of code, you have to recompile the entire application. This is obviously very cumbersome, and the uncertainty caused by software changes is very high. , The impact of software deployment is also very large. In the microservice architecture, the deployment of each service is independent. If a problem occurs, it only affects a single service, and it can be quickly rolled back to solve the problem.
Easy to optimize
The amount of code for a single service in the microservice architecture is not very large, so when you need to refactor or optimize this part of the service, it will be much easier. After all, the less the amount of code means the more controllable the impact of code changes. .
Disadvantages of microservices
We have been emphasizing the benefits of microservices above. However, the microservice architecture is not a panacea and cannot solve all problems. In fact, this is caused by the fact that microservices split the monolithic application into many small distributed services. The so-called multi-handed Miscellaneous, the service is more and the management is not good. Various problems arise.
In order to solve the shortcomings of microservices, the predecessors proposed the following concepts.
Service registration and discovery
Microservices call each other to complete the overall business function. How to find the correct target service address among many microservices is the so-called "service discovery" function.
The common practice is to report its address to the "Service Registration Center" when the service provider starts up. This is called "Service Registration". The service caller "subscribes" to the service change "notification", dynamically receives the service address list pushed by the service registry, and directly sends it to him which service he wants to find in the future.
Service monitoring
The monitoring operation and maintenance of a single program Fortunately, the service operation and maintenance of a large-scale microservice architecture is a big challenge. Service operation and maintenance personnel need to know the various statuses of the service in real time. It is best to have a control panel to see the service's memory usage, number of calls, and health status.
This requires us to have a complete service monitoring system, including topology, monitoring (Metrics), log monitoring (Logging), call tracking (Trace), alarm notification, health check, etc., to prevent problems before they happen.
Service fault tolerance
No service is guaranteed to be 100% free from problems. The production environment is complex and changeable. Various failures (downtime, overload, etc.) are inevitable during service operation. What engineers can do is to minimize the impact when a failure occurs. Scope and restore normal services as soon as possible.
Smart programmers introduced "service fault tolerance" mechanisms such as "fuse, isolation, current limiting and degradation, and timeout mechanisms" to ensure continuous service availability.
Service security
Some services have security issues with sensitive data. "Service security" is the use of a security authentication mechanism for sensitive services. Access to services requires corresponding identity verification and authorization to prevent the risk of data leakage. Security is a long-term topic. There is also a lot of work to be done in microservices.
Service governance
Speaking of "governance", it is generally only when there is a problem that it needs to be governed. We usually mean environmental governance and pollution control. There are more and more microservices in the microservice architecture, and the problems mentioned above become more apparent. To solve the above micro The service architecture defect "service governance" appears.
Those problems of microservices have to be solved by the company's technical team. If it were not for a large company with a mature technical team, it would be very big. Fortunately, there are giants who can lend us the shoulders and help us complete service governance by introducing a "microservice framework".
Microservice framework
Introduce some mature microservice frameworks in the industry.
Tars
It is an open source project based on years of practical results of TAF (Total Application Framework), a microservice architecture used internally by Tencent. Only C++ language is supported, and it is currently widely used within Tencent. Open sourced in 2017, only C++ language is supported.
Source code:https://github.com/TarsCloud/Tars/
Dubbo
It is a Java high-performance and excellent service framework open sourced by Alibaba, which enables applications to realize service output and input functions through high-performance RPC, and can be seamlessly integrated with the Spring framework. Apache Dubbo |ˈdʌbəʊ| is a high-performance, lightweight open source Java RPC framework that provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery. Open sourced at the end of 2011, only Java language is supported.
Official website:http://dubbo.apache.org/zh-cn/
tomcat
It is a Java framework open sourced by Sina Weibo. Motan has been widely used on the Weibo platform, completing nearly 100 billion calls for hundreds of services every day. It was open sourced in 2016 and only supports the Java language.
Official guide:https://github.com/weibocom/motan/wiki/zh_userguide
gRPC
It is a high-performance, general-purpose open source RPC framework developed by Google. It is designed by Google for mobile application development and based on the HTTP/2 protocol standard. It is developed based on the ProtoBuf (Protocol Buffers) serialization protocol. It is not distributed itself, so further development is needed to realize the functions of the above framework. The open source cross-language RPC framework in 2015 supports multiple languages.
Chinese tutorial:https://doc.oschina.net/grpc?t=58008
thrift
It was originally a cross-language high-performance RPC framework for internal systems developed by Facebook. In 2007, it contributed to the Apache Foundation and became one of the Apache open source projects. Like gRPC, Thrift also has its own set of interface definition language IDL, which can be generated by code It generates SDK codes for Client and Server in various programming languages, and supports multiple languages.
Microservice framework and RPC
Many people are a little confused about these two concepts. We have mentioned the microservice framework above, let's look at the concept of RPC.
What is RPC
RPC (Remote Procedure Call)Remote procedure call is a computer communication protocol. Our general program call is a call inside a local program, RPCallowing you to call another program's function like a local function, which involves network communication and inter-process communication, but you don't need to know the implementation details, the RPCframework shields you Low-level implementation. RPC is a server-client (Client/Server) model. The classic implementation is a system that exchanges information through "send request-receive response" .
Relationship between the two
RPCThe relationship with the microservice framework. A "microservice framework" generally includes RPCimplementation and a series of "service governance" capabilities, which is a software development framework. We can implement our own microservices based on this framework, and conveniently use the "service governance" capabilities provided by the microservice framework RPC能力, so the microservice framework is also called by some people RPC框架.
Next-generation microservice architecture
Service Mesh(Service Grid) is considered to be the next generation of microservice architecture Service Meshand does not bring us new functions. It is used to solve the problems of service network calls, current limiting, fusing and monitoring that have been solved by other tools. This time is the realization Cloud Native of the kubernetesenvironment.
Features
Service Mesh has the following characteristics:
-
The middle layer of communication between applications
-
Lightweight web proxy
-
Application unaware
-
Decoupling application retry/timeout, monitoring, tracking and service discovery
At present, the two popular Service Mesh open source software [Istio](https://istio.io/) and [Linkerd](https://linkerd.io/)both can be directly kubernetes integrated in it, and they Linkerdhave become 云原生计算基金会 CNCF (Cloud Native Computing Foundation) members.
Why Service Mesh
Why should the existing microservice architecture solve the problems still need to be used Service Mesh? This question is a good question.
Before answering the question , let istio.io’s take service mesha look at the correct explanation. I think it’s pretty good, so I can extract it:
❝As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, **with few or no code changes in service code. **
❞
Try to summarize: With the increase in microservices and the increase in complexity, management becomes more difficult. Although the microservice architecture solves the problems of "network calling, current limiting, fuse, and monitoring", most frameworks and open source software The original business is yes 侵入式, that is, the relevant "service governance" components need to be integrated in the business service program.
Service MeshFor microservices, as TCP/IPfor the Internet, TCP/IPit provides connection-oriented, reliable, byte-stream-based basic communication functions for network communication. You no longer need to care about the underlying retransmission, verification, flow control, and congestion control. .
Use Service Meshyou do not have to worry about the details of "service management" does not need to do special service transformation, by all business functions beyond Service Meshto help you do it. It is like a 轻量级网络代理 process that is transparent to applications, all traffic between applications will pass through it, so control of application traffic can be serivce mesh implemented in it.
Write at the end
No technology is timeless in the IT world. The evolution of microservice architecture is an example. From monolithic programs to microservice architecture to service mesh architecture , I don’t know when the next technology iteration will be, but it can It is certain that the microservice architecture will evolve, and IT people should establish the habit of lifelong learning.
reference
https://www.cnblogs.com/Zachary-Fan/p/service_manage_discovery.html
https://www.zhihu.com/question/56125281
http://dockone.io/article/3687
https://www.infoq.cn/article/micro-service-technology-stack
https://segmentfault.com/a/1190000010224335
https://book.douban.com/subject/26772677/
https://jimmysong.io/blog/what-is-a-service-mesh/
https://github.com/weibocom/motan/wiki/zh_userguide
------------------------------------------- < END >---------------------------------------
Architect's Path to Practice April 23
The following article comes from the back-end technology school, the author LemonCoder
https://mp.weixin.qq.com/s/RMEgkLUETSfpWzErfs50Qw