Micro Service and traditional service architecture

Micro Service and traditional service architecture

Monolithic architecture Applications: Functional centralization, code and data centralization, an application that runs in the same process after a release package is deployed

The advantages of a single block architecture:

1) Easy to develop

2) Easy to test

3) Easy to deploy

4 easy to scale (all functions will be a package, create a new node in the cluster, configure the operating environment of the node, copy the package to the location of the response, ensure that the distribution of load balance distribution policy effectively distributed to the current node)

Challenges to face:

1 maintenance costs increase, the code is too large, not conducive to rapid positioning problems

2 Continuous Delivery cycle long: The actual construction of deployment and testing will grow exponentially as the amount of code increases.

3 The new culture cycle long: business familiarity and environmental deployment will have a lot of difficulty

4 the high cost of technology selection: A larger scale system, the initial selection will affect the use of new technologies

5 Scalability Difference:

A vertical expansion: adding servers

b Horizontal Extension: Add nodes to the cluster, use load balancing (if the application is part of the need for memory-intensive cache of large amounts of data, part of the need for CPU-intensive, a large number of operations, so that each extension of the new node requires sufficient memory and CPU to meet the requirements)

6 The construction of a full-featured team is difficult: the expansion of the function will need to communicate across the team

Micro-Service Architecture:

is an architectural model that advocates dividing a single application into a small set of services, coordinating and cooperating with each other, delivering the ultimate value to the user, each running in a separate process, and using lightweight communication mechanisms between services to communicate with each other (usually based on HTTP restful APIs), Each service built around its own specific business, can be deployed independently, should try to avoid a unified, centralized service management mechanism, for a specific service, should be based on the business context, choose the appropriate language tools to build, namely:

By analyzing and modeling specific business areas, complex applications are decomposed into small, single-minded, low coupling and highly autonomous groups of services, each of which is a small application

The compiled language has good language type constraints and compile-time checking, but the code is more complex

Dynamic language flexibility is high, runtime can change its memory structure, no type check, no need to write more types of related code, but not convenient debugging

Development test deployment completely independent, language independent

Services and services are independent and isolated from each other

In a monolithic architecture, the code of the application is divided into logically 3 or 4 layers, but not physically layered, all of the features are compiled, packaged, deployed, or run in the same process, which means that the service that is running must be deactivated for the application deployment, and the process will be restarted after the deployment is complete. Unable to deploy independently

Generally for the reusability of the code, the duplicate code will be encapsulated into components (can be independently upgraded, independently replaced parts), in traditional architectures, usually shared libraries, such as jar packages or the DLL under win

But in a micro-service architecture, an application consists of multiple services, each of which is a highly autonomous, independent business entity, with each service running in a separate process that can easily be deployed to different hosts

It is theoretically possible to deploy different services to the same node, run into a different process, but not recommended, since it is a micro-service, it is best to ensure a high degree of autonomy and isolation, running on the same node, although the cost of the node is eliminated, but increased the complexity of deployment and expansion, the deployment of a new service, may have an impact on the original service of the node, and as the business progresses, there may be some business needs to expand horizontally, some do not need to, if not effective organization of services, may give the level of service expansion will cause unnecessary trouble

Docker:

1 faster delivery and deployment, developers can use a standard mirror to build a mirror, after development is completed, the operator can use this image directly to deploy

2 can be easier to migrate and expand, including physical machines, virtual machines and public cloud, private cloud, etc., this compatibility can easily transfer applications from one platform directly to another

3 simpler management, using Docker, all mirror modifications can be published and updated in an incremental manner, enabling automated and efficient management

Can effectively solve the micro-service architecture, service granularity, the number of services caused by the development of the environment to build, deployment and high operational costs of the problem

The essence of micro-service usually includes:

1) service as a component

2) Around the business organization team

3 focus on the product rather than the project

4) Technology Diversity

5) Business Data independence

6) Infrastructure Automation

7) Evolution Architecture

Correspondence Explanation:

1) service as a component

In the traditional field, we usually pull out the common parts, build shared libraries to decouple and reuse, but shared libraries are platform-and language-dependent, and applications running in the unified process, that is, shared library updates, means that the entire application is updated and needs to be redeployed, If there are multiple shared library components, any changes to the library will cause the application to be redeployed

Micro-services can also be considered as a component that runs in different processes, and each service change requires only the redeployment of its own services, across platforms, across languages

Of course, micro-services have its drawbacks, that is, distributed calls consume more time than in-process communication and rely heavily on the stability and reliability of the network.

2) Around the business organization team

In the traditional architecture, we usually divide the team according to the skill, understand the server's operational personnel, the user Experience Designer, the DBA, the backend developer, when the team is divided according to this dimension, some simple requirements change, may appear across the organization across the team collaboration, the cost of communication is high

Micro-service is to advocate business as the core to organize the team, the team members have a variety of skills

3 focus on the product rather than the project

Project model is the project start-up after the enterprise or organization will be from different skills resource pool to draw different resources to form a team and complete the project, project completion, team dissolution, the disadvantage of this model is the lack of team members sense of ownership, difficult to develop effective rewards and punishments mechanism, team members also lack of achievement

4) Technology Diversity

In the micro-service architecture, because of the independence of each other, can be for different business characteristics of different business selection, targeted solutions to business problems, such as requirements for rapid development of modules can use PHP python, the performance of a higher demand for modules can use C C + +, for a monolithic architecture, Switching language or frames, the difficulty will be relatively large, if not complete functional test set, it is difficult to smooth replacement, and the larger the system scale, the higher the risk

And for the micro-service architecture, we can pick a less risky access as an attempt to quickly get feedback and then judge whether it applies to other services, such a failure of the new technology will not affect the development of the entire product

5) Business Data independence

Different database types can be used to manage different data in a micro-service, such as

In a complex CRM system, the product data variety, the update is also more frequent, can use Monogo such document database, it can flexibly according to the demand dynamic adjustment

For the user to visit the system generated by the temporary session information, you can use the Redis and other key value system for storage

The structure of the report data is very small and requires data consistency, you can use the traditional MySQL database

Once the implementation of the micro-service architecture can be completed once, you may need to deploy each part separately, each service needs to be deployed health monitoring, error rollback, log analysis and other costs will increase significantly, automated deployment requirements are increasingly high, you can use the cloud DevOps Docker

Single all-inclusive platform has not been able to meet our needs, a single technology platform has been unable to adapt to the rapid changes in the market, organizations should continue to develop with the business to try new architectural design, truly to achieve business-driven architecture, architecture services in the business

Advantages of micro-service:

1 Independence 2) Single responsibility 3 technical diversity

Issues to be noted for deployment:

1 The complexity of the Distributed System 2) operation and maintenance cost 3 Deployment Automation 4) DevOps and organization 5 service Dependency Test 6) inter-service dependency management

Complexity of distributed systems:

1 performance due to the call across the network across the process, you must consider the network latency and the impact of the bandwidth

Especially when multiple services collaborate, the response time and performance impact on the system

2 Reliability due to network, bandwidth, node, such as the impact of their own reliability factors, any one of the components of the remote call, may fail, and the number of micro-services, the potential for more single point of failure, so to ensure the reliability of the system, reduce the network, components caused by the single point of failure rate, but also become a challenge

3 asynchronous due to the boast of network calls, the need to consider asynchronous communication mechanism, such a problem when debugging will become very troublesome

4 Data consistency in order to ensure data consistency, we usually consider distributed transaction management, but it will involve across multiple nodes to ensure the instantaneous consistency of data, compared to the traditional transaction costs will be much higher, usually, the final data consistency will be used to solve the data instantaneous consistent system is not available

5 Tool IDE tool, and does not provide good support for distributed calls

The effective construction group animation deployment pipeline, reduces the deployment cost, enhances the deployment frequency, is the Micro service architecture next jumps the war, the traditional system is split into many mutually cooperating independent services, as the number of micro-services increases, how to clearly and effectively show the dependencies between services, gradually become a challenge

Micro-service emphasizes a highly autonomous architecture model that independently develops independent testing independently and runs independently, and is a more flexible, open and loosely evolving architecture

Task split:

1 focus on a task at the same time

2) ability to do continuous integration of each completed part

3 The overall progress is easy to track