Micro-Service Architecture design

Micro-Service

A software architecture is a system organization that contains a variety of organizations, including Web servers, application servers, databases, storage, and communication layers, which have relationships with each other or with the environment. The goal of the system architecture is to address stakeholder concerns.

Conway ' s law:organizations which design systems[...] is constrained to produce designs which is copies of the Communica tion structures of these organizations.

(The organization of the design system, the resulting design and architecture are equivalent to the communication structure between organizations.) )

Monolithic architecture

Monolithic is more suitable for small projects, the advantages are:

Simple, direct, centralized management with minimal duplication of development

Features are local, with no distributed management overhead and call overhead. Its shortcomings are also very obvious, especially for Internet companies (not listed here):

Low development efficiency: all development in a project to change code, submit code to wait for each other, code conflicts constantly

Code maintenance Difficult: Code functions coupled together, new people do not know how to start

Inflexible deployment: Build time is long and any minor modifications must rebuild the entire project, which is often a long process

Low stability: a trivial little problem that can cause the entire application to hang out

Insufficient extensibility: inability to meet business requirements in high concurrency scenarios

Micro-Service Architecture

MicroServices are the development of a single, small, but business-capable service, each with its own processing and lightweight communication mechanisms that can be deployed on a single or multiple servers. MicroServices also refer to a kind of loosely-coupled, service-oriented architecture with a certain bounded context. That is, if each service is to be modified at the same time, then they are not microservices because they are tightly coupled, and if you need to master a service with too many context scenarios, then it is a service with a context boundary, which is defined by the DDD domain-driven design.

Its main features, relative to the monolithic architecture and SOA, are component, loosely coupled, autonomous, and centralized, in the following ways:

• A small set of services
  Service granularity is small, and each service is packaged with a single responsibility for the business capability, focusing on doing a good thing.

• Standalone deployment runs and extensions
  Each service can be deployed independently and run within a process. This mode of operation and deployment gives the system flexible code organization and release rhythm, making it possible to quickly deliver and respond to changes.

• Independent Development and evolution
  Technology selection is flexible and not subject to legacy system technology constraints. Choosing the right technology for the right business problem can evolve independently. The integration of a language-agnostic API between services and services. Relative to the monolithic architecture, the microservices architecture is an architectural model that is more business-oriented.

• Independent teams and autonomous
  The team is responsible for the entire life cycle of the service, working in a separate context, making decisions on its own governance without needing a unified command center. Teams and teams connect through loose community tribes.

We can see the idea of the entire microservices as we now face the explosion of the explosive, knowledge explosion is the same: by decoupling what we do, divide and conquer to reduce unnecessary losses, so that the entire complex system and organization can quickly respond to change.

Why do we use micro-services?

"Let our system respond to change as quickly as possible"-Rebecca Parson

Let our system respond as quickly as possible to changes. In fact, we have been trying to solve this problem for decades. If you must put a limit on the front, that is the low cost of rapid response changes. In the 90 's, Kent Beck offered to embrace change, with a number of lightweight development approaches (such as XP, Scrum) in the same period, and the 2001 Agile Manifesto, followed by new ways of managing lean, Kanban, and more. If this is to respond to changes as quickly as possible, in terms of software development processes and practices, the MicroServices architecture is the answer that is presented at the software technology and architecture level.

Autonomous
A microservice is a unit of functionality; It provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A microservice is a unit of deployment; It can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; It can horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; It is fault tolerant and highly available

Responsive
A microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system are found in the Microservice endpoints

Message oriented
MicroServices rely on HTTP or a lightweight message bus to establish a boundary between components; This ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
MicroServices provide API ' s for access by developers and administrators

composable
Applications is composed from multiple microservices

Automated
The lifecycle of a microservice is managed through automation that includes development, build, test, staging, production and distribution

How to communicate between services

General synchronous invocation is relatively simple, strong consistency, but easy to call the problem, the performance experience will be worse, especially when the call hierarchy more. The comparison of restful and RPC is also a very interesting topic. General rest based on HTTP, easier to implement, easier to accept, server-side implementation of the technology is more flexible, the language can support, while cross-client, there is no special requirements for the client, as long as the package of HTTP SDK can be called, so the relative use of a wide range of. RPC also has its own advantages, the transport protocol more efficient, more controllable security, especially within a company, if there is a unified development norms and unified service framework, his development efficiency advantages more obvious. Just look at their own technology to accumulate the actual conditions, their own choice. And the way of asynchronous message in the distributed system has a very wide range of applications, he can reduce low-key service between the coupling, but also can become a buffer between calls, to ensure that the message backlog will not be washed out by the callee, while guaranteeing the service experience of the caller, continue to do their own work, not to be slowed down by background performance. However, the price to pay is the reduction of consistency, the need to accept the final consistency of the data, and the background service is generally to achieve idempotent, because the message is sent for performance reasons are generally duplicated (to ensure that the message is received and received only once for performance is a great test); Finally, a separate broker must be introduced. , if there is no technical accumulation within the company, the broker distributed management is also a big challenge.

Micro-Service Benefits

• Each micro-service is small enough to focus on a specific business function or business requirement.
• Micro-services can be developed by small teams, a small team of 2 to 5 developers.
• MicroServices are loosely coupled and functional services that are independent both during the development phase and at the deployment stage.
• MicroServices can be developed using different languages.
• MicroServices allow for easy and flexible integration of automated deployments through continuous integration tools such as Jenkins, bamboo.
• New members of a team can be put into production faster.
• MicroServices are easily understood, modified, and maintained by a developer, so small teams can focus more on their work outcomes. There is no need for cooperation to embody value.
• MicroServices allow you to leverage the latest technologies for integration.
• MicroServices are just code for business logic and do not mix with html,css or other interface components.
• MicroServices can be expanded on demand immediately.
• MicroServices can be deployed on servers with low-end configurations.
• Easy integration with third parties.
• Each micro-service has its own storage capacity and can have its own database. You can also have a consolidated database.

Disadvantages of the MicroServices architecture

• MicroServices architectures can lead to excessive operations.
• Requires DevOps skills (HTTP://EN.WIKIPEDIA.ORG/WIKI/DEVOPS).
• Probably double the effort.
• Distributed systems can be complex and difficult to manage.
• Because the distribution deployment tracking problem is difficult.
• As the number of services increases, management complexity increases.

Issues to consider

• A single micro-service code is small, easy to modify and maintain. However, the total amount of system complexity is constant, each service code is less, but the number of services is definitely more. Like a jigsaw puzzle, the more broken it is, the harder it is to spell the whole picture. A system is split into fragmented microservices, and finally set to become a complete system, and its complexity is certainly much higher than that of large chunks of functional integration.
• Individual microservices data is independent and can be deployed and run independently. Although the microservices themselves can be deployed and run independently, but still avoid the business you come to me, this involves the external communication, when the number of micro-services reached a certain level, how to provide an efficient cluster communication mechanism becomes a problem.
• A single micro-service has its own process, the process itself can be dynamic start and stop, for the seamless upgrade of the foundation, but who to start and stop the process, what time, choose which device to do this thing is the key to seamless upgrade. This capability is not provided by the microservices themselves, but rather requires a powerful version management and deployment capability behind it.
• Multiple identical microservices can do load balancing, improving performance and reliability. It is because the same microservices can have multiple different instances, which makes it possible to dynamically scale services on demand, and at peak times, more of the same microservices instances can be started to serve more users, increasing responsiveness. At the same time, this mechanism also provides high reliability, after a micro-service failure, the other same micro-service can take over its work, the external performance of a device failure after the business is not interrupted. Similarly, the microservices themselves are not concerned about the system load, then when should start more microservices, how the traffic of multiple microservices should be dispatched and distributed, which is behind a set of complex load monitoring and equalization system in effect.
• Micro-services can be deployed independently and externally to provide services, micro-service business on-line and offline is dynamic, when a new micro-service on-line, how users access to this new service? This requires a unified portal, the new service can be dynamically registered to the portal, the user can access each time from this portal to the system all services access address. This unified system portal is not part of the microservices themselves, so this capability needs to be provided separately by the system.
• There are also enterprise-level concerns about system issues, such as how security policies are centrally managed? How can system failures be quickly audited and tracked to specific services? How is the system state monitored? How is dependency between services managed? And so on. These issues are not a single micro-service consideration, but need a systematic consideration and design, so that each microservices can provide the corresponding security, reliability, maintainability ability according to the requirements and constraints of the system.

Why API is important

? The essence of service value reflects
? reliable, usable, readable
? only one chance.

Implement an API gateway as the only entry for all clients. The API Gateway has two ways of handling requests. Some requests are simply proxied/routed to the appropriate service, and other requests are forwarded to a set of services.

Compared to providing a pervasive API,API gateway, different APIs are opened according to different clients. For example, the Netflix API gateway runs client-specific adapter code that provides the client with the most appropriate API for its needs.

The API gateway can also implement security, such as verifying that a client is authorized to make a request.

Design elements

? Version
? Requstid
? Auth&signature
? Ratelimit
? Docs
? Errorcode&message

Micro-service governance

? scale on Demand
– Deployment and monitoring of operational costs
? Standalone deployment
– Number of machines and deployment costs
? Business Independence
– Service dependencies, governance, versioning, transaction processing
? Technology diversity
– Environmental deployment costs, agreed costs

? Run state governance
– Monitoring, current limit, SLA, LB, log analysis
? service registration and Discovery
? deployment
– Rapid, reproducible, and scalable
– Single-Machine development
? call
– Security, fault tolerance, service demotion, call latency

Service Fault Tolerance

When the enterprise microservices, there will be a complex dependency between services, for example, a front-end request will generally rely on multiple back-end services, technically known as the 1-n fanout. In a real-world production environment, services are often not reliable, services can be faulty or delayed, and if an application cannot fault-tolerant and isolate the failures it relies on, the application itself is at risk of being dragged down. In a high-traffic web site, once a single backend is delayed, it can cause all application resources (threads, queues, and so on) to be exhausted in a few seconds, resulting in the so-called avalanche effect (cascading Failure), which can paralyze the entire site in severe time.

Service dependent

Service Framework

1. Service Registration, discovery, load balancing, and health checks, assuming an in-process lb scenario, the service self-registration is generally unified in the server-side framework, the Health check logic is customized by the specific business services, the framework provides a mechanism to invoke the health check logic, Service discovery and load balancing are integrated into the service client framework.
2. Monitoring logs, the framework on the one hand to record important framework layer logs, metrics and call chain data, but also to expose the log, metrics and other interfaces, so that the business layer can record business log data as needed. In the running environment, all log data is generally centralized to the enterprise backend log system for further analysis and processing.
3. Rest/rpc and serialization, the framework layer to support the business logic in the Http/rest or RPC exposure, http/rest is the current mainstream API exposure, in high performance requirements can be used BINARY/RPC way. For the current variety of device types (browsers, ordinary PCs, wireless devices, etc.), the framework layer to support a customizable serialization mechanism, for example, to the browser, the framework supports the output of AJAX-friendly JSON message format, and the native App on the wireless device, The framework supports binary message formats with high output performance. The
4. configuration, in addition to the configuration that supports the normal profile approach, enables the framework layer to integrate dynamic runtime configuration to dynamically adjust service parameters and configurations for different environments at run time.
5. Current-limiting and fault-tolerant, framework-integrated fault-tolerant components enable automatic current-limiting and fault-tolerant, protection services, and dynamic current limiting and fusing if combined with dynamic configuration. The
6. management interface, which integrates management interfaces, allows you to view the internal state of the framework and services online, while also dynamically adjusting the internal state to provide quick feedback for debugging, monitoring, and management. The actuator module of the Spring boot micro-framework is a powerful management interface.
7. Unified error handling, which is useful for service monitoring and rapid problem positioning if the framework layer is able to process and log logs uniformly for the internal exceptions of the framework layer and service.
8. Security, security, and access control logic can be encapsulated at the framework level, and can be made into plug-in forms, and the specific business services load the relevant security plug-in as needed.
9. document Generation, document writing and synchronization has always been a pain point, if the framework can support the automatic generation and synchronization of documents, the use of API developers and testers greatly facilitated. Swagger is a document scheme for popular restful APIs.

Micro-service System base

A complete microservices system with a minimum of the following features in its base:

• Log and audit, mainly log summary, classification and query

• Monitoring and alerting, mainly monitoring the status of each service and generating alarms when necessary

• Message bus, lightweight MQ or HTTP

• Register Discovery

• Load Balancing

• Deployment and upgrade

• Event scheduling mechanism

• Resource management, such as: underlying virtual machines, physical machines and network management

The following features are not part of the minimum set, but also belong to the base function:

• Certification and authentication

• MicroServices Unified Code framework that supports multiple programming languages

• Unified Service Building and packaging

• Unified Service Testing

• Micro-service CI/CD pipeline

• Service Dependency Management

• Unified Issue Tracking Debug framework, commonly known as call chain

• Grayscale Publishing

• Blue-Green Deployment

Containers (Docker) and microservices

The container is small enough.
– Addressing the demands of micro-services on the number of machines
? container Independent
– Solving multiple language problems
The development environment is the same as the production environment
– Single-machine development, increased efficiency
? High container efficiency
– Save money
? Code/image Integration
– Reusable Management System
? Horizontal and vertical expansion of containers
– Can be duplicated
– Dynamically adjusts CPU and memory

Containers (Docker) and microservices

? Image Management
? system security Management
? Authorization management
? Maturity of the system
? Community Maturity

Development style Impact

With the continuous delivery concept and the popularity of Docker containers, microservices combine these two concepts and technologies to form a new development model for the MicroServices +api + platform, and propose the concept of continuous delivery of containerized microservices.
The traditional monolithic DevOps development team approach:

This monolithic architecture requires product teams to develop QA DBAs and system operations management across product management Dev, while microservices architectures are introduced, such as:

MicroServices facilitate the reorganization of a devops approach, dividing a bloated overall product development team into product teams based on different microservices, and a large overall platform team responsible for operational management, which interacts with each other through APIs to achieve loose coupling isolation.

• The first step is to consider building a devops capability, which is the source of power to ensure the continuous delivery and response of the microservices architecture to complex operational issues;
• Second, to maintain the continuous evolution of services so that they can be quickly and cost-effectively split and merged to quickly respond to business changes;
• Keep the team and the architecture aligned at the same time. Micro-service seems to be a technological change, but it has a strong demand and influence on team structure and organizational culture. The team that identifies and builds the matching architecture is another pillar of the solution.
• Finally, creating a self-organizing culture of continuous improvement is the key cornerstone of implementing microservices. Only continuous improvement, continuous learning and feedback, and continuously create such a culture atmosphere and team, the micro-service architecture can continue to develop, maintain fresh vitality, so as to achieve our original intention.

The implementation of microservices is a prerequisite: basic operational capabilities (such as monitoring, rapid provisioning, rapid deployment) need to be built ahead of time, or you will fall into a passive situation like ours. Recommend the use of infrastructure and code practices, through the code to describe the computing and network infrastructure methods, so that the pattern I can quickly and securely set up and handle the server replaced by the new configuration, the server can have higher consistency, reduce the "My environment work, and your environment does not work," the possibility of It also provides a better support for subsequent release strategies and operations.

Because of the introduction of Docker, different microservices can use different technical architectures, such as node. js Java Ruby python, and so on, these individual services can complete the delivery lifecycle independently, as follows:

Micro-service Case

Netflix's micro-service architecture focuses on global distribution of high scalability and availability:

Twitter's microservices architecture with an emphasis on efficient and scalable data centers:

--------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------

Hope to your system architecture, software project development, operation and maintenance management, system architecture and research and development management system, information security, enterprise information and other help. Other articles you might be interested in:
A few examples of cloud computing reference architectures
Introduction to micro-services and Docker
Internet Live Platform Architecture case One
High-availability Architecture case One
The technical structure of an internet company advertisement platform
Practice of a large-scale electric clouds platform
A few examples of cloud computing reference architectures
Mobile app app testing and quality management one
Comprehensive Software Testing
An introduction to the SSO Single sign-on solution for well-known ERP vendors
Introduction to software project Risk management
Introduction of enterprise project management
One of intelligent Enterprise and informatization
From the basic qualities of entrepreneurs
Method and practice of quality assurance of agile software
Build efficient research and development and automated operation and maintenance
Introduction to it operation and maintenance monitoring solution
Quality management of it continuous integration
Talent company environment and corporate culture
The Balanced scorecard of enterprise performance management system
Corporate culture, team culture and knowledge sharing
High-Performance Team building
Food chain Company It informatization solution One

If you want to know more software development, system it integration, Enterprise informatization, project management, business management and other information, please follow my subscription number:

Petter Liu
Source: http://www.cnblogs.com/wintersun/
This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.
The article was also published in my Independent blog-petter Liu blog.

Micro-Service Architecture design