Foreword
With the Internet in the early 2000s on a large scale access, Internet-based traffic by the publisher of profitable clicks unilateral information Web 1.0 business models, leading change by user-generated content and Web 2.0 business model. Therefore, the volume of data traffic and Internet applications needed to handle the rapid growth in back-end technology architecture and therefore faces enormous challenges.
Back-end architecture of the Internet Web 2.0 phase of the most experienced by the All in One monolithic application architecture gradually to a more flexible architecture of distributed application process, the development of Internet infrastructure began to pursue higher quality and efficiency.
With the advent of smart phones and the popularity of 4G standards, Internet applications from the PC end quickly turned to freer movement end. Since the mobile device convenient and easy to locate, and therefore completely changed the modern way of life in terms of travel, online shopping, payment and other carry. On the technical side, in order to cope with much larger cluster size, a simple distributed system has been difficult to control, and therefore opens up a technical circle concept outbreak of the era --SOA, DevOps, container, CI / CD, micro-services, Service Mesh concepts after another, the emergence of Docker, Kubernetes, Mesos, Spring cloud , gRPC, Istio other products, marking the cloud era has truly arrived .
This article (or this series of articles), is himself after reading Sam Newman's "micro-services," a book, and other micro-service design-related articles, after associate reading to do "from the service of the cloud native" and other books the summary notes.
The purpose is to build a distributed micro-service system of the tree of knowledge of cloud native area.
At the same time we want to reinforce learning can help to you.
I, on the micro-services
1.1 What is a micro-service
Micro small and self-service is some of the work of the service.
Key words: small and autonomy
"small"
"Small" concept, on the one hand reflected in the cohesion of the micro-services.
- Cohesion can also be called a single principle functions: " the variations due to the same reason what aggregated together, but for different reasons to change something separated. "
- In other words, micro-services should focus on doing one thing.
- To determine the boundaries of the service by the service boundary
On the other hand the size of the code embodied in the library, there are several standard or reference principles
- Small code base to match the team structure
- Codebase as small easy to quickly rewrite
- Dialectical view. The smaller the services, advantages and disadvantages of micro-services architecture is also more obvious
autonomy
"Autonomy" concept, emphasized that a micro service is a separate entity. Reflected in the loose coupling between services.
- The golden rule: if you can modify and deploy a service without affecting any other services?
The key point: To learn the correct modeling services, the correct design services API, in order to achieve the above-mentioned two points.
1.2 Benefits of micro-services
Most of the benefits of micro-services are applicable to distributed system architecture, these benefits will only micro-services to the extreme
- Technical heterogeneity
- Different services based on business scenarios, performance requirements, functional requirements using different technology architecture
- Rapid practice of the new technologies, the rapid growth of the technical team
- Elastic / trans vulnerability (anti-fragility)
- Service downgraded
- Disaster recovery services, service fuse
- Spread
- Traditional single system, can not be done to extend the functionality of the local
- Depending on business needs, be extended for a specific micro-services
- By means of architecture, cost savings
- Simplify deployment
- Traditional single application, even if the line of code is modified, the overall need to redeploy. Too risky.
- Micro-service architecture, each service deployed independently of each other
- Flexible version made way
- Fast rollback
- low risk
- Architecture and organizational structure to match
- Related knowledge: Conway's Law
- Service reusable, can be combined
- Substitutability services, quick rewrite
1.3 Service Oriented Architecture
SOA (Service-Oriented Architecture, Service Oriented Architecture) is a design methodology, which includes a plurality of services, and ultimately provides a series of functions between the service by blending. A service normally present in the operating system processes in an independent form. Between service calls through the network, and not by way of in-process calls to communicate.
Like XP or Scrum is considered the same as a particular method of agile software development, micro-services architecture is a particular method of SOA .
SOA implementation problems encountered:
- Communication Protocol (SOAP or REST)
- Selection of third-party middleware
- Service granularity division
- ......
Thinking and Summary
Micro service does have a number of advantages: "anti-vulnerability (anti-fragility)", fault-tolerant, independent deployment and expansion, abstract architecture, technology isolation. But not to say that it uses a micro-service naturally have these characteristics.
For example, to have anti-vulnerability, we need to fully consider the uncertainties of distributed systems, asynchronous clear, network segmentation, node failures, balance availability and data consistency issues .
Likewise, we should have maintainability and scalability, we must first have the appropriate infrastructure and organizational structure .
In theory, micro-services can improve development speed, but when you create organizations rely on, "micro-services commission (MicroservicePremium)" may reduce the speed of development.
Therefore, the use of micro-services architecture requires a number of prerequisites, including the right of sustained release pipeline, capable of DevOps and Ops team, prudent service boundaries and so on. In addition, thorough testing and integration mode is also very important.
To the extent that this last chapter speak of: Micro service is not a silver bullet, you have to do a lot of work in terms of deployment, testing and monitoring. You also need to consider how to expand the system, and to ensure their elasticity even need to deal with similar distributed transaction, CAP-related issues.
I think this is why the services of native to the cloud is the trend, because only in conjunction with "+ container choreography scheduling" cloud platform, micro-services to their advantage to play to the maximum. As cloud native knowledge, but also the contents of the back.
Great God extended reading Martin Fowler article
Micro service commission www.martinfowler.com/bliki/Micro...
Second, how to model service
Or we would like to reiterate two important concepts, high cohesion and loose coupling , the corresponding front Keywords: small and autonomy .
2.1 concepts
Bounded context
The authors cite here the concept of (the book is highly recommended reading) Eric Evans book "Domain Driven Design" in: bounded context .
Any given bounded areas includes a plurality of contexts, each bounded what context (Eric more commonly used model of the word, it should be more than "something" better) is divided into two parts, need not communicate with the outside, the other part of it is necessary. Each context has a clear interface that determines which model it will be exposed to other contexts. Using a cell as an analogy: "Cell reason there is, because of the membrane defines what intracellularly, extracellularly what, and determine what the substance through the cell membrane."
Hide sharing model and model
At the same time also mentioned the concept of a shared model and behind model.
Sharing model that models the interaction between the context analogy model of hiding is not required to interact with the external model.
On how to start micro-services, in view of the book and with the TW Martin Fowler is a point of view: "MonolithFirst" - single application first.
Mainly for the following considerations:
- Yagni principle - to determine the usefulness of software ideas, the best way is to create a simplified version, and then look at its results. At this stage, the most important thing is speed, which can shorten the feedback cycle principle, to avoid micro-services commission.
- Clearly bounded context set - there is only good and stable border services, micro-services in order to function effectively. However, functional remodeling services between any micro-architecture in the monomer than difficult, even experienced architects in familiar areas where it is difficult to properly define the boundaries in the beginning, and the first building a single application in favor of clear functional boundaries.
Extended reading www.martinfowler.com/bliki/Monol...
Of course, and they are in the business environment is certainly a great relationship, ThoughtWorks is a help other companies solve the problem of consultants, that is to say, they will help if a company monomers application problems, the its reconstruction micro services architecture. We conclude that is understandable. About this industry there are other voices, such as direct start from the micro-services.
I am more inclined to be this way, so in this way the excerpts and learning.
2.2 Modeling Highlights
-
Avoid premature division
The system is divided prematurely become a micro-service price is very high, especially in the face of new areas. In many cases, an existing code base will be divided into micro-services, is much easier than starting from scratch micro service.
-
OK bounded context
Use module bounded context modeling, using both shared and hidden models.
-
Starting from business functions
When thinking bounded context, it should start from the business function, you must first ask yourself "This context is what to do with," and then consider "what kind of data it needs."
-
Gradually divided context
When considering micro boundary and services, first consider a relatively large, that the context of the coarse-grained, and then found that when the appropriate slot, and then further divided into those nested contexts.
- Nesting context
- Top-level context
Thinking and summary
How to find cohesion and low coupling to achieve high internal seams in the problem space. Bounded context is a very important tool for finding these seams , by micro-services match those boundaries, we can ensure that the final system is able to get all the benefits of micro-services provided.
This part can be associated with learning DDD philosophy books.