Foreword
Originally planned three-day weekend Friday + traveling by car, who knows the unexpected outbreak coincided with Saturday typhoon, Huzhou nearby attractions all closed down, only a last resort comes to an end after Friday, Saturday stepping typhoon Shanghai edge fled. Flies so difficult weekend, this time to talk about something retreat topics, micro-architecture design First Talking about service, and second, Eureka and RPC framework Dubbo talk about the similarities and differences in micro-services widely used service governance.
First, the micro-architecture design services
The reason want to talk about this topic, mainly realizing the two new micro-services projects recent contact - architecture design of two projects by the hands of two people, but without any intent to use the same design concept, project structure is very similar . Thought worked on the structural design of the company when exposed to the project, then burst out a slight idea. With micro-architecture design services to the agenda, very noisy Quchong bias, so the need to declare it, the paper said, are based blogger shallow experience in software development and architecture design barren current drawn humble opinion, is the only one of the words, but which must contain a lot of confirmation bias type, which now can not be avoided. The purpose of this article is to share with you their ideas, nothing more.
Closer to home, the current spread more widely and more mention of the design concept, comes in 2004 Eric Evans raised Domain Drive Design, namely domain-driven design, referred to as DDD. The concept can be said that the micro-services have considerable symbiotic dependence, and therefore, until recent years, the rise of micro-services, DDD design concept was popular. The design concept is to first determine the field, and then design and develop on this basis. And how to understand the field? Popular way is to be understood that a separate service module to determine a boundary of the range of service areas. Electricity suppliers to the project as an example, the shopping cart can be seen as a field, place orders as a field, a mall as a field, and when too large an area of development time, and then be split into finer field points, the principle is to ensure that each of these areas to do a single thing, so that the greatest degree of decoupling.
The actual project as an example, a project will be divided into three one module, namely micro startup class service module, the core business modules, common middleware technology modules. And each module has a number of two modules, each module is a two fields, such as two modules in service modules are: mall, shopping cart, orders, and payments. Technical module: redis module, Swagger module, a database module, and so the message queue module. Business modules and technology modules two modules are unified integration by starting class module that determines which services need to micro-module which is used. This arrangement can be combined for maximum flexibility to existing modules.
Some slightly advanced technical staff know that there is no perfect architecture design, only more suitable for the design of the current scene. Good architecture can not be resolved once and for all future problems, but can definitely provide great convenience to you in solving problems.
Two, Eureka and Dubbo
Now online, more is to compare with Dubbo and Spring Cloud, compare similarities and differences from the micro-module functions and services. But this comparison is a bit biased, Dubbo positioning service governance is to do more, rather than providing a package of micro-services architecture solutions, it is more the result of this function is the Spring Cloud have that function, but this is not that no Dubbo. Today, from the perspective of service governance with a commonly used Eureka Spring Cloud and Dubbo comparison, look at the similarities and differences between the two.
To say that both have to mention the CAP distributed architecture theory, that a distributed framework, can only meet the consistency C, the availability of two A, P partition network fault tolerance of the three, it is impossible while both the three.
From this point of view, Dubbo recommended registry of choice for ZK, while ZK is a framework to meet the CP; Eureka because of its architecture, more focused on the AP.
For fault tolerance, Dubbo itself implements a number of error handling, such as failover Failover, rapid failure Failfast, fail safe Failsafe etc., Eureka is by means of a fuse Hytrix Spring Cloud in the implementation of fault tolerance.
For load balancing, Dubbo itself to achieve a variety of load balancing methods, such as random weights, hash consistency, Eureka is also putting this functionality, such as through the Ribbon realizes load balancing.
Service registration and discovery, Dubbo itself encapsulates NettyClient and other communication tools, and Eureka are based on the application layer communications HttpClient.
It can be seen, micro-services using the frame itself is split art design, relatively independent split different functions into separate modules, like modules on what combination of what modules. From this point of view, more Dubbo is to provide a non-split the overall functionality combined with Eureka and other components are simple, lightweight and more.
postscript
In fact, you can then extend further, this feeling of DDD concept of micro-services, can be compared to human society division generated performance. Every type of work on behalf of a field, different internal areas can do their function, through the division of labor can greatly enhance the productivity of society as a whole, and by dividing the field, but also can improve a framework, an organization working efficiency. Everything Everything has contact, the ancients I sincerely do not bully.