Micro-Service Architecture (MSA)

What is micro-service architecture

From the industry's discussion, the microservices themselves do not have a strict definition. However, the description of ThoughtWorks's chief scientist, Martin Flowler, is more understandable:

A microservices architecture is an architectural pattern that advocates dividing a single application into a small set of services that are coordinated and co-ordinated to provide the ultimate value to the user. Each service runs in its own separate process, with a lightweight communication mechanism between the service and the service (typically HTTP-based restful APIs). Each service is built around a specific business and can be independently deployed to a production environment, a class production environment, and so on. In addition, a unified and centralized service management mechanism should be avoided as far as possible, and for a particular service, it should be based on the business
Select the appropriate language and tools to build it.

The original text reads as follows:

In short, the Microservice architectural style was an approach to developing a single application as a suite of small servi CES, each running in it own process and communicating with lightweight mechanisms, often an HTTP resource API. These services is built around business capabilities and independently deployable by fully automated deployment machinery . There is a bare minimum of centralized management of these services, which could be written in different programming Languag ES and use different data storage technologies.

–james Lewis and Martin Fowler

features of the microservices architecture

The essential features of microservices typically include the following sections: Services as components (componentization via services) around the business organization team (organized-around-capabilities) Product not project (products not Projects) hardening terminal and weakening channel (Smart endpoints and dumb pipes) decentralized governance (decentralized governance) Decentralized data management (decentralized data Management) infrastructure automation (Infrastructure Automation) fault-tolerant design (designer for failure) evolutionary architecture (evolutionary Design)

Micro-service is a new Internet architecture, the basic idea is to split a mast system into a number of small service components, communication between components with a light-weight protocol, such as rest API. MicroServices are essentially extended extensions of SOA (serviceoriented Architecture). In contrast, microservices are more operable and can be arranged in a reasonable way, to decompose a large system, or at least to stop it from becoming bloated.

Micro-Service has the following advantages: According to the independent vertical development of business functions, easy to develop, understand and maintain; support heterogeneous development language, not limited by any technology stack, short deployment cycle, automated Deployment (docker/kubernetes), local modification is easy to deploy, facilitates continuous integration and continuous delivery; Fault isolation, a service problem does not affect the entire application; single application vs microservices application

In layman's words, "Monomer application (Monolith application)" is to package all the functions of an application into a separate unit, which can be a jar, WAR, ear, or other archive format. Monomer application has the following advantages: Suitable for small team start-up rapid development; Easy to test: because there is no additional dependency, each test can start immediately after the deployment is complete, simple to deploy: simply copy a single archive file to the Tomcat WebApps directory; There is no distributed transaction problem;

However, no matter how modular, the single application will eventually be due to team expansion, access to more and more applications and other problems. This is mainly reflected in the following areas: inflexible : any minor modifications to the application require the entire application to be rebuilt and redeployed. Developers need to wait until the entire application deployment is complete before they see the change. If multiple developers work together to develop an application, wait for other developers to complete their own development. This reduces the flexibility of the team and the frequency of functional delivery, hindering continuous delivery : Monomer applications can be large, the build and deployment times are correspondingly longer, are not conducive to frequent deployment, and hinder continuous delivery. Limited by Technology stack : For such applications, technology is selected after careful evaluation prior to development, and each team member must use the same development language to have an oom effect on the overall application after a service is present; reference

1.Microservices by Martin Fowler
2.Microservices Resource Guide
3.microservices:decomposing applications for deployability and Scalability