So here I probably divided into several schools:
conservative:
Most of the scene itself is already a single Big Mac systems, consideration is how to split the problem, split less of it, achieving the desired effect of splitting, but also increases the overall complexity, it is better not split; split too broken it, Intuit big workload, equivalent to redo. So compromise and, probably in accordance with the size of the system, the system is split into a large one of the few medium-sized systems .
For example, the original project is a mall system, including the Mall reception, order management, product management, and other back-office functions .
After the split: Mall reception, individual centers, mall background .
Advantages: not very clear, but it already has performance scalable store front (mostly concentrated in the client performance mall), and subsystems may be slightly improved usability.
Inadequate: Performance stretch very limited because the bottleneck in the data set level, once the card is in operation such as orders, product data, the card that dang does not improve.
Summary: This is the existing system of micro-services only way, first dismantling the system into multiple systems, and then continue to split into more small systems, but in the process of splitting very elegant business architecture design capabilities, comprising extracting common services, dividing the range of a single service, the service call path after the original resolution level is not too deep like.
Extreme faction:
Willy-nilly, to the overall design, ideas, according to a micro-CURD split into a service project this coming.
In fact, this is certainly a more pursuit of the ultimate style, each equivalent to a single business function to split the project into a micro-services.
Advantages: If the data link layer, and each service call properly designed, is indeed a very good program, together with a set of micro-management services and continuous integration framework, the entire system is very clear, very high availability and scalability.
Inadequate: for business design requirements is still very high, and for the development team collaboration and document requirements are very high, to achieve a business of their own, now across multiple projects, individuals, inevitably efficiency will be reduced.
Summary: In good overall team collaboration, detailed environmental document, which would be a ideal framework program. On the contrary it, efficiency will be greatly reduced, and after running the project as a whole controllability is not optimistic.
Rationalism:
Actually, the best solution is completely in accordance with the actual situation to consider the plan.
Is a big team or a small team? Split the extreme, for a large team, it is able to improve the overall efficiency of parallel collaboration after a lot of back-end staff previously only a serial amount of work done, services of micro.
Micro service is a long-term, sustainable integration process, the original system of micro-services need not be done overnight, can be staged large-scale demolition, the demolition of the small, small micro demolition.
Micro-service design small example:
Currently in charge of several projects bloggers do, and some still in the giant mode, some new projects, it is a big hand with dozens of micro-engineering services, each with its own benefits and egg pain point of it.
Previous chapter tells about the content of the concept SpringCloud Alibaba, component, and other initial use.
Next, I want to take a small but perfectly formed electric provider demo, come to a more reasonable structure to a complete practice micro-services architecture.
Probably so long, I have not started writing the code, after this series Take this example unfurl. (Really wanted to write a complete series of practical micro-services)
This is my micro preliminary design services, basically based on the service module is divided + drawn attention to the public such an idea, we can also discuss Kazakhstan.
