How small systems are "microservices" developed

Referring to "micro-services", I believe that the various "micro-services" on-line evolution of the case will give people a "because of the big divide" The premise illusion, which may lead to a lot of "small white" has no opportunity to contact the "big project" and the "micro-service" is expected to be impossible. Of course, this illusion may be more derived from the "micro-technology" of "endless" so "dazzling", such as spring Cloud. Although the "big project" opportunity is not much, but also can not stop "nails" through the tutorial to the micro-technology run over to decorate their "micro" self-confidence.

"Micro" is just a normal thinking logic

Think of that year, the entry, such as the market, the same as small white, can be the SSH framework to run a time unexpectedly can bring themselves incredibly strong work confidence. Who does not have a "capital" age, but unfortunately its own "impetuous" forced back to pursue the "essence" of calm and calm. In the era of the Internet's emergence, the focus of the system may not lie in the "Horizontal distribution" of "monomer" applications, but more on the "vertical layering" of the overall business. Regardless of the horizontal or vertical points, the essence of "points" is actually because of "heavy". "Divide and conquer" should be regarded as the most basic human thinking logic. But the concrete realization of the "points" is also attributed to the question of what is standing on our opposite side. The internet is the main thrust of the "business" from the offline to the line, in the initial development stage of the Internet, it is possible to embody the integrity of the online business, so the thickness of the business becomes the bottleneck, so the vertical division of the business logic level may be the key solution at that time. With the popularization of mobile internet, "online business" has become the mainstream, the business of "thick" has accumulated to another level, simple "vertical stratification" has been unable to meet the accumulation and support of heavy business. Business is broken down into a breach. A large number of "distributed" scenarios arise, including "microservices". From many "big and micro" initial phenomenon, it is very easy to "big" and "micro" link together, this is also "big" enterprises in the forefront of the times to face the "uncertainty opportunity" to "create" phenomenon. History can easily give people a "know what they do" view of the overall situation, but time actors are easy to be limited to the current. I personally think that the essence of "micro-service" is a kind of normal thinking, is a basic problem-solving ideas. "MicroServices" is not new, with 26 of commonly used object-oriented design patterns, with the accumulation of time experience will become our problem-solving "benchmark moves." Therefore, it can be speculated that the future development is inseparable from the "micro-service" thinking mode of guidance, such as the project or the organization's management model may change, or has been quietly changed. If "microservices" are really like the way I analyze a mindset, then there will be no big projects or small projects.

Micro-service Mode small case

In the process of work, after all, a small number of major projects is the test of technical people "grounding gas" performance. One day, I received a small-scale "phone recharge system" demand, not too many complex functions and logical description, is a user can be in the above self-recharge system. The rest of the understanding, depends on the work experience of their own skill. In the face of this need, the first thing I think about is this key business process:

This process said simple can be simple, said the complex can be "comparable" e-commerce system, such as "recharge amount" equivalent to goods, "recharge" equivalent to shopping, "order" to run away, "recharge the phone" analogy logistics. All kinds of e-commerce "boundary problem" almost all have to consider, the size is small, but five zang have to have. As for "five Zang", this has to be based on the boundaries of the business to divide the "business area", first of all, according to their experience to try a:

This kind of business division is somewhat similar to the e-commerce system, which directly presents the business model. According to "MicroServices" thinking, each domain is a separate unit of service units, and each service "object" has its own "attributes" and "behaviors":

The properties of each service are "service identity", "service name" and so on, of course, the service has its own behavior (more in the API), various system external actions are through the "cooperation" between the services to complete:

 

User View Recharge Amount: pick up the Goods service ("recharge 10 yuan to account 12 Yuan", "recharge 100 yuan to account 106 yuan", ... ）；

user initiated call Recharge: order service receive request → Order Service Inquiry product information (product ID) → order service to pay the service under the order → order service to recharge the service under the recharge order → order service itself under the order of goods;

User payment: payment Gateway (peripheral) Accept request → callback payment service notification payment result → payment service update payment order status → payment service to recharge service start recharge → recharge service to recharge the gateway (peripheral) to initiate the recharge and change the status of the top-up order;

Order Reconciliation: timed Payment gateway reconciliation, timed recharge order reconciliation:

From the above process can be seen, each service has its own focus on the "function", each application business process requires 1 or N services to complete the interaction, each service has its own independent "data source", non-interference. Since the initial size of the system is expected to be small, it is possible that hundreds of orders per day may even be less, if we need "physical isolation" of each service, it is a bit blowing out. As a result, the project was initially implemented in "monomer" mode:

The so-called "monomer", that is, all the service code together with a "project" packaging release, that is, a "normal" project and share a database, but the table name of each service has a service identity (contract), such as the Product service related table names named "Kw_goods_xxx", the Order service related table name to "Kw_order_xxx" name, the related table name of the payment service is named "Kw_payment_xxx", the related table name of the recharge service is named "Kw_recharge_xxx", the related table name of the reconciliation service is named "Kw_account_xxx". Services should never cross service operations database tables, must be called according to the "Business process design", so "monomer" is only embodied in the physical implementation level, the logic level has always maintained the "microservices" distributed characteristics, retaining a variety of code can not modify a line of flexibility to expand the possibility of:

One might ask, how does the service invocation of the "monomer" mode be tuned? How is the "distributed" mode tuned? How do you ensure that the service code call level is not changed during the extension? What kind of technology is used? This essay does not talk about too much technology, service invocation process I probably through the pseudo-code diagram:

The key to the "transparency" of collaboration between services is to package the "change" of the "microservices" flexible characteristics, which is the discoveryclient calling agent of the above pseudo-code. Discoveryclient maintains information about all services within the technical framework (service data Cache Container), and how service information is loaded is the key to service decoupling. First, the framework scans and loads all local service information into a "service container" (locally scanned LocalService) through local scanning. Second, the framework detects the local "service Information" configuration file and loads it into the container (static parsing). Finally, the framework determines whether a Discovery Center service exists and dynamically updates the service information (dynamic parsing) to the Discovery Center, based on the service information that was loaded in the first two steps of the configuration. Therefore, whether a single application deployment or a distributed application deployment, the service invocation is transparent and retains the flexibility of the entire system. Here, the whole system is basically finished, and the complete system architecture diagram is as follows:

Above system without any preferential normal operation, really can only be a small scale, a single server deployment model enough to support, but in the monthly membership day launched "100 yuan to send 10 yuan" commodity, monomer application seems a little force, The increase in access to goods and services (see more people) has affected the stability of other services, and has considered the stability of the reconciliation (lest the top-up accounts for complaints), and decided to put the commodity services and reconciliation services Independent (process) deployment. Service distribution by joining the Gateway (Nginx) (Service decoupling):

In the operation process, the company in order to "traffic management", at the expense of the launch of "charge 100 yuan to send 50 yuan" commodity, the system once again by the severe test, in order to the quality of business, have to all services independent (process) deployment, increase support strength:

Do not know whether the boss drink more or short-circuiting operation, unexpectedly mention a "recharge 100 yuan to send 100 yuan" commodity, and tomorrow on-line, the system peak support concurrency prediction has exceeded my imagination, I can do only this:

System from the scale of business does exist in size, but from the design thought level, the system is not the size of the points. The above "show widening" are to serve as a unit of flexible expansion, in fact, the smallest business force is the specific behavior of the service-api, each API is a service independent behavior, such as query, change, etc., fully conform to the "Command query separation of Duties (CQRS) mode" design, By service This API granularity of horizontal decomposition is also feasible, such as "payment service" there is the payment Order query API, payment order API, payment results notification receiving API, we can read and write features to the query API and change Class API separation, can also be oriented to "consumer" The angle of the decomposition:

If some businesses have complex service chains (such as commodity orders), you can also customize the complexity of the Orchestration service to decouple the underlying service:

Learning Summary

If the careful point can be found from the above cases, my whole project development process with the traditional may be a little different, what difference? There is not much to highlight the physical object design or table structure design, not to highlight the so-called "three-layer structure" design, but directly from the business perspective to trigger the division of "Business Objects", and our services are presented according to the Business domain division of "Object" description, and the traditional press "data entity" The division of the design pattern is still a certain difference, from demand design to software design and development are "business model" the most original and most intuitive presentation, to ensure business accuracy and reduce the risk of change costs, and also greatly reduce the project's communication costs. This idea has a more professional term called "Domain driven Design". I know that I have a long distance from the so-called "microservices" or "domain-driven design", and there may be a lot of detail in the above cases, but this kind of thinking is really a design habit that I have developed from my own business and gradually thinking and settling. It is not what others say, but the practice of thinking and understanding and learning from the "Masters" of the true source.

How small systems are "microservices" developed