1. Introduction
With the development of the Internet industry, more and more open source technologies such as frameworks, middleware and containers are emerging to better serve business, realize business and solve problems. But with so many technology options, how do we identify the right technology for our team’s business? For people, shoes that are too big may affect their running speed, while shoes that are too small may affect the growth of the body. Technology is also relevant to business.
Therefore, compared with the skills of learning, building, using, operation and maintenance of technology, our selection of technology is a top priority. Then how does the Dubbox framework to be discussed in this paper stand out among many service frameworks and be selected by the team to practice the road of service?
2. The service
2.1 Why service
Technology is born for the business, architecture is born for the business. Along with the development of the business, the growth of the users, system, called dependencies also becomes complex, in order to make sure the system high availability, high concurrency requirements and architecture of the system is also from monomer time slowly migrated to service the SOA era, according to the requirements of different services on system resources is different, we can be more reasonable configuration system resources, maximize the system resource utilization.
1. Single application architecture
When site traffic is low, only one application is needed to deploy all functions together to reduce deployment nodes and costs.
At this point, data access frameworks (ORM) that simplify the work of adding, deleting, modifying and reviewing are key.
2. Vertical application architecture
When the volume of traffic gradually increases, the acceleration caused by the increase of a single application machine is getting smaller and smaller. The application is divided into several unrelated applications to improve efficiency.
At this point, a Web framework (MVC) for accelerating front-end page development is key.
3. Distributed service architecture
With the increasing number of vertical applications, the interaction between applications is inevitable. Core businesses are extracted as independent services, gradually forming a stable service center, so that front-end applications can respond to changing market demands more quickly.
At this point, the distributed Services framework (RPC) for business reuse and integration is key.
3. Mobile computing architecture
As the number of services increases, problems such as capacity evaluation and waste of small service resources gradually emerge. In this case, a scheduling center needs to be added to manage cluster capacity in real time based on access pressure to improve cluster utilization.
At this point, a resource scheduling and Governance center (SOA) for improving machine utilization is key.
Platforms can meet business needs from an All in One environment as the business evolves (in the case of Java, a war package or two might solve the problem); To develop to need to split multiple applications, and adopt MVC way to separate the front and back end, accelerate the development efficiency; In the development of more and more services, some core or common services have to be split out to provide real-time flow monitoring computing, in fact, at this stage, if the Service split fine enough, and independent operation, this time at least can be understood as a SERVICE-ORIENTED Architecture.
2.2 Service challenges
In the era of service SOA, we are faced with many problems to be solved, such as increased system complexity, service dependency, service performance monitoring, full-link logging, disaster recovery, circuit breakers, and traffic limiting. So why do distributed services in the face of these problems? Because only by forging ahead in the future can we go higher and farther. But don’t get discouraged when you see these problems. Let’s take a step by step look at what the problems are and what we’re trying to accomplish, and they’ll take care of themselves.
According to the current situation of the team’s business system, first of all, we need to sort out the existing problems:
Then, when choosing the technical framework, the technical framework should basically solve the existing problems above, and at the same time, we should also confirm our expectations and what the goal is to achieve:
And the most important point, which is often a lot of technical personnel into the mistake, “for technology, do not use for the sake of use, with the most simple and appropriate technology to solve the problem is the right way”. An architecture serves the business. An architecture that can meet business requirements quickly and conveniently is a good architecture.
2.3 Future trend of services
When it comes to services, many of you may have heard of SOA, MSA and other service concepts. In recent years, MSA has been very popular. In fact, behind each concept is to solve different problems. The biggest characteristic of this kind of noun is that it is easy to understand when explained, not to know when asked, and to fight when discussed.
Both SOA and MSA are ultimately an architectural approach to providing interfaces. In fact, with the development of the Internet, the emergence of complex platforms and services leads to the development of SOA architecture to a more fine-grained and generalized degree, which becomes the so-called microservices. With this statement in mind, I see SOA as different from microservices in the following ways:
Microservices have a lot in common with SOA. Both are typical system architectures with loosely coupled distributed components. Microservices provide a clearer, more well-defined way to create an architecture around the concept of services. The principles of microservices are highly aligned with agile software development thinking, and they share the same goal as the evolution of SOA principles to reduce the high complexity of traditional enterprise service bus development. The key difference between the two is that microservices focus on generating value in an autonomous way. But the intent behind the two architectures is different: SOA attempts to integrate applications, typically using a centralized management model to ensure that applications can interact. Microservices try to deploy new features and scale development teams quickly and efficiently. It focuses on decentralized management, code reuse, and automated execution.
Microservices are not an approach to new ideas. It is more of a refinement of ideas, a refined evolution of SOA, and a better use of advanced technologies to solve problems such as containers and automation. Therefore, when we choose the service technology framework, it is not black and white, but for SOA and MSA architecture design at the same time to consider the compatibility, for the existing platform architecture design, retreat to defend SOA, advance to attack MSA, stage selection suitable.
3. The framework
There are many mature service frameworks in the industry, such as: Hessian, CXF, Dubbo, Dubbox, Spring Cloud, gRPC, thrift and other technologies can be implemented for remote call. The pros and cons of specific technologies can be analyzed as follows, which is also an important basis in the selection of specific technical solutions.
3.1 Comparison of service frameworks
Dubbo is an open source Java high-performance service framework developed by Alibaba, which enables applications to realize the output and input functions of services through high-performance RPC, and can be seamlessly integrated with the Spring framework. However, it is a little sad that dubbo is said to have been disbanded in Taobao due to competition with another similar framework HSF (non-open source). Instead, Dubbox, an expanded version of Dangdang, is still in continuous development. Some other well-known e-commerce companies, such as Dangdang and Gome, maintain their own branches or develop on the basis of Dubbo, but the official library lacks maintenance and related dependency classes, such as Spring, Netty is still very old (Spring 3.2.16.RELEASE, Netty 3.2.5.final), but some people have written plug-ins to upgrade Spring and Netty.
Dubbox and Dubbo are essentially the same, the meaning of the name is an extension of Dubbo, the following extended functions, is also a very important research point to choose Dubbox.
Spring Cloud is completely based on Spring Boot. It is a very new project, with a 1.0 release released in 2016. Currently, Github updates quickly. Although Spring Cloud has the shortest time, compared with RPC frameworks such as Dubbo, Spring Cloud provides a full range of distributed system solutions. Spring Cloud provides developers with tools to quickly build in distributed systems (configuration management, service discovery, fuses, routing, micro proxy, control bus, one-time Token, global lock, Leader election, distributed Session, cluster state). Developers using Spring Cloud can quickly launch services or build applications. They will work in any distributed environment, including developers’ own laptops, data centers for bare physics machines, and Cloud management platforms like Cloud Foundry. In the future, we will lead the development of this micro-service architecture and provide a set of industry-standard micro-service architecture solutions.
The disadvantage is that the project is very young, it is rare to see people in the domestic industry to use the whole set in production, generally there are only one or two components. The technical documentation is mostly in English, and there are relatively few cases, so it takes longer to learn.
Here’s a comparison of Spring Cloud and Dubbo:
Motan is an open source Java framework for Sina Weibo. It started late, in 2013, and opened in May 2016. Motan is already widely used on the microblogging platform, making nearly 100 billion calls a day to hundreds of services. Compared to Dubbo, Motan isn’t as comprehensive in terms of features and doesn’t have as many extensions. Fewer people use it, and its function and stability remain to be seen. Poor support for cross-language calls, mainly Java.
Hessian uses the binary RPC protocol and is suitable for sending binary data. However, it is also a Web Service framework to support RPC calls, which is simple and easy to use. Transmission is based on Http. Provide remote services through servlets. Requests are made through the API provided by Hessain itself. The responder accepts the request based on the API provided by Hessian.
Hessian advantages:
RPCX is the Dubbo of the Go language ecosystem. It is lighter than Dubbo and implements many features of Dubbo. With the excellent concurrency features and concise syntax of Go language, distributed RPC services can be implemented with less code.
GRPC is a high-performance, universal open source RPC framework developed by Google. It is mainly developed for mobile applications and designed based on THE HTTP/2 Protocol standard. It is developed based on the Protocol Buffers (ProtoBuf) serialization Protocol and supports many development languages. It is not distributed per se, so further development is required to implement the functionality of the framework above.
Thrift is a cross-language high performance service framework of Apache, which has been widely used.
Comparison of the above RPC framework functions:
Selection in actual scenarios
3.2 RPC vs. REST (JAX – RS)
Since Dubbo is a basic framework, whether the content of its implementation is reasonable for us to implement microservices architecture needs to be considered according to our own needs. For example, Dubbo’s service invocation is implemented through RPC. However, if you have read Martin Fowler’s article MicroServices carefully, The communication between services it defines is the REST API of the HTTP protocol. So what’s the difference between the two?
1. The interface dependence between the service provider and the caller is too strong
We define a service abstract interface for each microservice, and publish it to a private warehouse through continuous integration. The caller application has a strong dependency on the abstract interface provided by microservice, so strict version dependency management is required regardless of development, testing and integration environment. In this way, there will not be a series of problems such as application failure to compile due to inconsistency between the server and the caller, and this will directly affect the environmental requirements of local development. Often, an upper-layer application that relies on many services will have to update a lot of code and install every day before subsequent development. Without strict version management or the development of automated tools, such dependencies can be a nightmare for development teams. And REST interface than RPC is more lightweight, dependence on the provider and the caller just rely on a paper contract, there is no code level strong dependence, REST interface, of course, also have pain points, because the interface definition too light, it is easy to cause the definition document do not agree with actual implementation result in service integration problems, but the problem is very good, Just integrate Swagger for each service, integrating code and documentation for each service. Therefore, in distributed environment, REST mode service dependency is more flexible than RPC mode dependency.
2. Services are platform sensitive and difficult to be easily reused
Usually when we provide external services, we will provide them in the REST way, so that we can realize the characteristics of cross-platform, and the caller of any language can be implemented according to the interface definition. In Dubbo, to provide the REST interface, we had to implement a layer of proxy to convert the RPC interface into a REST interface for external distribution. If each of our services itself exists as a REST interface, when we want to provide services externally, we can realize the reuse of services mainly by configuring the mapping relationship and permission control in the API gateway.
I believe these pain points are one of the reasons why Dangdang has added REST support in DubBox, an open source extension based on Dubbo.
Dubbo has realized the foundation of service governance, but to complete a complete microservice architecture, it needs to be expanded and improved in every link to ensure the health of the cluster, to reduce the pressure on development, testing and operation and maintenance, so that all link personnel can truly focus on business logic.
Spring Cloud still carries forward Spring Source’s all-in-one style, integrates some mature products and frameworks of micro-service architecture in a standardized manner, and inherits Spring Boot’s characteristics of simple configuration, rapid development and easy deployment. Make the complex architecture work relatively easy to learn.
Therefore, if you choose Dubbo, it is important to prepare the whole solution at every stage, otherwise the team will be overwhelmed by the difficulties caused by the lack of architecture as the number of services increases. If you choose Spring Cloud, relatively speaking, each link has the corresponding component support, some may not meet all your needs, but its active community and high-speed iteration schedule will also be a strong backing you can rely on.
4. What does Dubbox bring
4.1 Dubbo Service Governance
4.2 Dubbox Extended Features
