Micro Services Architecture Overview

1.1 Application Architecture monomer present problems

  A package archive (e.g. war format) contains all the features of the application, often referred to as single use .

  Here are some of the problems monomer present application:

  * High-level complexity : The module contains the whole project is very large, fuzzy boundary between modules, dependencies are not clear, code quality is uneven, chaotic piled together .. the whole project is very complex, modify the code every time scared, even Add a little bug will bring hidden defects.

  * Technical Debt : Over time, the demand for change, personnel iteration, the debt will gradually form a technical application. System design or code that has been used is difficult to be modified, because the program modules may be other unexpected use it.

  * Low Frequency deployment : With the increase in code, build and deployment time increases. In the single application, every change or repair the defective functions will lead to redeploy the entire application. Full deployment of the amount of time-consuming, affecting large-scale, high-risk, so the lower the frequency of application deployment monomer. The deployment has led to low frequencies have a lot of bug fixes and feature changes between two releases, a high probability of error.

  * Poor reliability : an application bug, such as an infinite loop, OOM, etc., may cause the entire application to crash.

  * Limited expansion capability : single application can only be extended as a whole, can not be scaled as needed to service modules. For example, some modules are computationally intensive, requiring powerful CPU; some module is IO intensive, requiring large memory. Since the deployment of these modules together and had to make a decision on the choice of hardware.

  * Impede technological innovation : single applications tend to use a unified technology platform or solution to all the problems, all the team members must use the same development languages and frameworks will be very difficult to want to introduce a new framework or technology.

  

  Monomers present application a lot of problems, there is no pattern to solve a framework can solve these problems? Service is one such micro architecture.

1.2 What is a micro-service

  Micro-architectural style is a kind of service to a single application development services for a group of small ways, each service runs in its own process, lightweight communication mechanism (usually HTTP resource API) between the use of the service. These services build around business capabilities and can be deployed independently by automatic deployment mechanism.

  Micro-service architecture features:

  * Each micro-services can operate independently in its own process.

  * A series of micro-services independently operated jointly build the entire system.

  * Each service is independent of business development, a micro-services only concerned with a specific function, such as order management, user management.

  * Service between micro communicate through some lightweight communication mechanism, such as make calls via RESTful API.

  * You can use different languages ​​and data storage technologies.

  * Automatic deployment mechanism.

Advantages and disadvantages 1.3 micro services

  advantage:

  * Ease of development and maintenance : a micro service will focus on a specific business function, so his business is clear, smaller amount of code. Development and maintenance of a single service is relatively simple. The entire application is constructed by a plurality of micro-services from, the entire application is also a controllable state maintained.

  * A single micro service starts fast : a single micro-services less code to start faster.

  * Partial modification is easy to deploy : single application as long as the modifications, you have to redeploy the entire application, micro-services to solve such a problem. In general, a micro-service modifications, simply re-deploy the service.

  * Technology stack unrestricted : the micro-service architecture can be combined with the characteristics of the project team and business, a reasonable choice of technology stack.

  * Scale on demand : according to demand and achieve fine-grained expansion. For example, a service system encountered a bottleneck, according to the characteristics of the micro-business services, increasing memory, CPU upgrade or add nodes.

  insufficient:

  * Operation and maintenance demanding : more services with more thought put into operation and maintenance. In single architecture, only we need to ensure the normal operation of an application. In the micro-services, the need to ensure the normal operation and collaboration of dozens or even hundreds of services.

  * Distributed inherent complexity : the use of distributed systems to build micro-services. For a distributed system, fault-tolerant systems, network latency, distributed transaction will bring great challenges.

  * Interface to adjust the high cost : a communication through an interface between the micro service. If you modify certain micro API services, we may use all of the micro-service interface needs to be adjusted.

  * Duplication of effort : many services are likely to use the same function, and this function did not reach the degree of decomposition of a micro-services, at this time, each service will be possible to develop this function, resulting in code duplication. Although you can use shared libraries to solve this problem. (For example, this feature can be packaged into a public assembly, micro-services need this feature refer to the component), but shared libraries in a multi-language environment will not be able to do the same up.

 

Design Principles 1.4 micro services

  * Single Responsibility Principle : a unit (classes, methods, services) should be concerned only part of the whole system functions alone, there are limits. Single responsibility principle to help us develop more elegant, more agile delivery.

  * Service principle of autonomy : each micro-services should have an independent operational capacity, dependent on the operating environment. In the micro-services architecture, the service is a separate business unit, should be highly decoupled and other services. Each micro-services from development, test, build, deploy, you should be able to run independently and not rely on other services.

  * Lightweight communication mechanisms : should interact through service between micro lightweight communication mechanism.

  *微服务的粒度:微服务的粒度是难点,也常常是争论的焦点。应当使用合理的粒度划分微服务,而不是一味的把服务做小。

  

 

Guess you like

Origin www.cnblogs.com/tc971121/p/11627781.html