Micro service

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

Conway’s Law: Organizations which Design Systems […] are constrained to produce designs which are copies of the communication structures of these organizations.

(Organizations that design systems produce designs and architectures that are equivalent to communication structures between organizations.)

Monolithic architecture

Monolithic is more suitable for small projects, with the advantages of:

Simple and direct development, centralized management, basic will not repeat development

Functionality is local, with no distributed administrative overhead or invocation overhead. Its disadvantages are also obvious, especially for Internet companies (not to mention) :

Low development efficiency: all developers change code in a project, submit code waiting for each other, code conflicts

Code maintenance is difficult: The code is functionally coupled and newcomers don’t know where to start

Inflexible deployment: Build times are long, and any small changes must rebuild the entire project, which is often a long process

Poor stability: A trivial problem that can cause an entire application to fail

Poor scalability: Unable to meet the service requirements under high concurrency

Microservices 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 server. Microservices also refer to a variety of loosely coupled service-oriented architectures with bounded contexts. That is, if every service is modified at the same time, they are not microservices because they are tightly coupled; If you need to master too many contextual scenarios for a service, then it is a context-bounded service, defined from DDD domain-driven design.

Compared with monomer architecture and SOA, its main characteristics are componentalization, loose coupling, autonomy and decentralization, which are reflected in the following aspects:

  • A small set of services

    Service granularity is small, and each service is a encapsulation of business capabilities for a single responsibility, focused on doing one thing well.

  • Run and scale independently

    Each service can be independently deployed and run within a process. This way of running and deploying gives the system a flexible code organization and release rhythm that enables rapid delivery and responsiveness to change.

  • Independent development and evolution

    Flexible technology selection, not constrained by legacy system technology. Choosing the right technology for the right business problem can evolve independently. Services are integrated with language-independent apis. Compared with single architecture, microservice architecture is a more business-oriented architecture pattern.

  • Independent teams and autonomy

    The team is responsible for the entire life cycle of the service, working in an independent context, making its own decisions and governing itself without the need for a unified command center. Teams connect with each other through loose tribes of communities.

We can see that the whole idea of microservices is the same as we are now dealing with the explosion of information and knowledge: by decoupling what we do, divide and conquer to reduce unnecessary wastage, and enable whole complex systems and organizations to respond quickly to change.

Why do we use microservices?

“Make our system responsive to change as quickly as possible.” – Rebecca Parson

Let our system respond to change as quickly as possible. We’ve been trying to solve this problem for decades. If I had to put a limit on that, it would be low-cost rapid response to change. Kent Beck’s embrace of change in the 1990s coincided with the emergence of lightweight development methodologies (XP, Scrum); Agile Manifesto was born in 2001, and then lean, Kanban and other new management methods emerged. If these are proposed solutions to software development processes and practices in order to respond to changes as quickly as possible, then microservices architecture is proposed solutions to software technology and architecture.

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 be 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 is found in The Microservice endpoints not ‘on The wire’

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 are composed from multiple Microservices

Automated

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

How do services communicate with each other

Generally, synchronous invocation is simple and consistent, but it is prone to invocation problems and poor performance experience, especially when there are many invocation layers. The comparison between RESTful and RPC is also an interesting topic. General REST based on HTTP, easier to implement, easier to be accepted, the server side implementation technology is more flexible, each language can support, at the same time can cross the client, there is no special need for the client, as long as the PACKAGING OF THE HTTP SDK can be called, so the relative use of a wider number of. RPC also has its own advantages. The transmission protocol is more efficient and the security is more controllable. Especially in a company, if there is a unified development specification and a unified service framework, its development efficiency advantage is more obvious. See respective technical accumulation actual condition, his choice. And asynchronous messaging way have special widely used in the distributed system, he can not only reduce the coupling between the call service, and can be invoked, the buffer between the backlog of messages will not be washed out by the caller, at the same time can guarantee the caller service experience, get on with their work, from the background slow performance. But the price to pay is the loss of consistency, the acceptance of final consistency of data; In addition, background services are generally idempotent because messages are sent repeatedly for performance reasons (ensuring that messages are received only once is a big performance test). Finally, it is necessary to introduce an independent broker. If there is no accumulation of technology within the company, the distributed management of brokers is also a great challenge.

Advantages of microservices

  • Each microservice is small enough to focus on a specific business function or business requirement.

  • Microservices can be developed independently by small teams of two to five developers.

  • Microservices are loosely coupled, functional services that are independent of each other during development or deployment.

  • Microservices can be developed in different languages.

  • Microservices allow an easy and flexible way to integrate automatic deployment through continuous integration tools such as Jenkins, Bamboo.

  • A new member of a team can go into production faster.

  • Microservices can be easily understood, modified, and maintained by a single developer so that small teams can focus on their own work. You don’t have to collaborate to be valuable.

  • Microservices allow you to leverage the latest technology.

  • Microservices are just code for business logic, not mixed with HTML,CSS, or other interface components.

  • Microservices can be extended on demand instantly.

  • Microservices can be deployed on servers in low – and mid-range configurations.

  • Easy integration with third parties.

  • Each microservice has its own storage capacity and can have its own database. You can also have a unified database.

Disadvantages of microservices architecture

  • Microservice architectures can introduce too many operations.

  • The conversation skills are needed (http://en.wikipedia.org/wiki/DevOps).

  • Maybe double the effort.

  • Distributed systems can be complex and difficult to manage.

  • Because distributed deployment tracking is difficult.

  • As the number of services increases, management complexity increases.

Questions to consider

  • A single microservice code is small, easy to modify and maintain. However, the total amount of system complexity remains the same, with less code per service but more services. Like a jigsaw puzzle, the more pieces you cut, the harder it is to fit the whole picture. When a system is broken down into fragmented microservices and finally integrated into a complete system, the complexity is definitely much higher than the large functional integration.

  • Single microservice data is independent and can be deployed and run independently. Although microservices themselves can be deployed and run independently, they still cannot avoid the exchange of business, which involves external communication. When the number of microservices reaches a certain level, how to provide an efficient cluster communication mechanism becomes a problem.

  • Individual microservices have their own processes that can be dynamically started and stopped, setting the stage for a seamless upgrade, but who starts and stops the process, when, and on which device you choose to do it is the key to a seamless upgrade. This capability is not provided by microservices themselves, but requires strong versioning and deployment capabilities behind them.

  • Multiple identical microservices can be used for load balancing to improve performance and reliability. Because the same microservice can have multiple different instances, it is possible to dynamically scale the service on demand. During peak times, more same microservice instances can be started to serve more users, thus improving the response speed. This mechanism also provides high reliability. If a microservice fails, other microservices can take over its work, ensuring that services are not interrupted when a device fails. Similarly, the microservice itself does not care about the system load, so when should more microservices be started and how to schedule and distribute the traffic of multiple microservices, which also has a complex load monitoring and balancing system at play.

  • Microservices can be deployed independently and provide external services. The online and offline services of microservices are dynamic. When a new microservice is online, how can users access this new service? This requires a unified entrance, new services can be dynamically registered to this entrance, users can get access to all services from this entrance every time. This unified system entry is not part of the microservice itself, so this capability needs to be provided separately by the system.

  • There are also system issues of enterprise concern, such as how can security policies be centrally managed? How to quickly audit and track system failures to specific services? How is the system status monitored? How are dependencies between services managed? These issues are not the scope of individual microservices, but need a systematic consideration and design, so that each microservice can provide the corresponding security, reliability, maintainability capabilities according to systematic requirements and constraints.

Why are apis important

• The essence of service value

• Reliable, usable and readable

• Only one chance

Implement an API gateway as a unique entry point for all clients. The API gateway handles requests in two ways. Some requests are simply brokered/routed to the appropriate services, while others are forwarded to a set of services.

Instead of providing a universal API, API gateways open different apis for different clients. For example, the Netflix API Gateway runs client-specific adapter code that provides the client with the API best suited to 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

• the Docs

• ErrorCode&Message

Microservice governance

• Scale on demand

– Deployment and monitoring o&M costs

• Independent deployment

– Number of machines and deployment cost

• Business independence

– Service dependency, governance, version management, and transaction processing

• Technological diversity

– Environment deployment cost and contract cost

• Health governance

– Monitoring, traffic limiting, SLA, LB, and log analysis

• Service registration and discovery

• deployment

– Rapid, replication, and capacity expansion

— Standalone development

• call

– Security, fault tolerance, service degradation, and call delay

Service fault tolerance

After enterprise microservitization, there will be complex dependencies between services. For example, a front-end request will depend on multiple back-end services, technically known as 1 -> N fan out. In real production environments, services are often not 100 percent reliable, errors can occur or delays can occur, and an application is at risk of being dragged down if it is not fault-tolerant and isolated from the failures on which it depends. In a high-traffic site, delays on a single backend can cause all application resources (threads, queues, etc.) to be exhausted in seconds, causing what is known as Cascading Failure and, in severe cases, bringing the entire site to its knees.

Service dependencies

Service framework

  1. Service registration, discovery, load balance and health checks, assume that the scheme of in-process LB services since the unified registration usually do on the server side framework, health check logic by specific business service customization, logic framework layer providing call health check mechanism, service discovery and load balance are integrated in the frame of the service client.

  2. Monitoring logs. On the one hand, the framework should record important framework layer logs, metrics and call chain data, and expose interfaces such as logs and metrics so that the business layer can record business log data as needed. In the operating environment, all log data is stored in the enterprise background log system for further analysis and processing.

  3. REST/RPC and serialization. The framework layer should support exposing business logic in HTTP/REST or RPC mode. HTTP/REST is the mainstream API exposure mode. For various device types (browsers, common PCS, wireless devices, etc.), the framework layer should support a customizable serialization mechanism. For example, for browsers, the framework supports the output of Ajax-friendly JSON message format, while for Native Apps on wireless devices, the framework supports the output of high-performance Binary message format.

  4. Configuration. In addition to supporting configuration in the form of common configuration files, the framework layer can also integrate dynamic runtime configuration, which can dynamically adjust service parameters and configurations during runtime for different environments.

  5. Traffic limiting and fault tolerance. The framework integrates traffic limiting and fault tolerance components to automatically limit traffic and fault tolerance at runtime, protect services, and, if further combined with dynamic configuration, achieve dynamic traffic limiting and fusing.

  6. Management interface, framework integration management interface, on the one hand, you can view the internal status of the framework and services online, but also can dynamically adjust the internal status, debugging, monitoring and management can provide rapid feedback. The Actuator module of the Spring Boot micro-framework is a powerful management interface.

  7. Unified error handling. If the framework layer can handle and log internal exceptions of the framework layer and service in a unified manner, it helps service monitoring and problem locating.

  8. Security and access control logic can be encapsulated uniformly in the framework layer and can be made into plug-ins. Specific business services load relevant security plug-ins according to their needs.

  9. Automatic document generation, document writing and synchronization has always been a pain point, if the framework layer can support automatic document generation and synchronization, it will bring great convenience to developers and testers using API. Swagger is a popular Restful API documentation scheme.

Base for the microservice system

For a complete microservice system, its base should contain at least the following functions:

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

  • Monitoring and alarms are used to monitor the status of each service and generate alarms when necessary

  • Message bus, lightweight MQ or HTTP

  • Registration found

  • Load balancing

  • Deployment and Upgrade

  • Event scheduling mechanism

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

The following functions are not part of the minimum set, but are also base functions:

  • Authentication and authentication

  • Microservices unified code framework that supports multiple programming languages

  • Unified service build and packaging

  • Unified service Testing

  • Micro service CI/CD pipeline

  • Service dependency management

  • Unified problem tracing debugging framework, commonly known as call chain

  • Gray released

  • Blue green deployment

Containers (Docker) and microservices

• Containers are small enough

— Solve the demand of micro services on the number of machines

• Container independence

– Solve the multi-language problem

• The development environment is the same as the production environment

– Single development, improve efficiency

• High container efficiency

– save money

• Code /image integration

– Reusable management systems

• Horizontal and vertical capacity expansion of containers

– can be replicated

– The CPU and memory can be dynamically adjusted

Containers (Docker) and microservices

Image management,

• System security management

• Authorization management

• System maturity

• Community maturity

Development mode impact

With the promotion of the concept of continuous delivery and the popularity of Docker container, microservice combines these two concepts and technologies, forming a new development model of microservice +API + platform, and proposing the concept of continuous delivery of containerized microservice.

Traditional Monolithic DevOps development team approach:

This holistic architecture requires the product team to span product management, Dev, development, QA, DBA, and system operation management. After the introduction of micro-service architecture, it is shown as follows:

Microservices catalyzed the reorganization of the DevOps approach, dividing a large, bloated product development team into product teams based on microservices and a large platform team responsible for operations management, with loose coupling between the two through API interactions.

  • First, consider building DevOps capabilities, which are the source of motivation to keep microservices architectures delivering and addressing complex operations issues.

  • Secondly, keep the service continuous evolution, so that it can be quickly and low-cost split and merge, in order to quickly respond to business changes;

  • At the same time, keep the team and architecture aligned. Microservices may seem like a technological change, but it has a strong demand and impact on team structure and organizational culture. Identifying and building teams that match architectures is another pillar of problem solving.

  • Finally, building a self-organizing culture of continuous improvement is a key cornerstone for implementing microservices. Only through continuous improvement, continuous learning and feedback, and continuous building of such a culture and team, can the micro-services architecture continue to grow, maintain fresh vitality, and achieve our original intention.

There are certain prerequisites for the implementation of microservices: basic operational capabilities (such as monitoring, rapid configuration, rapid deployment) need to be built in advance, otherwise we will be in a passive situation like ours. Infrastructure and is recommended for the code of practice, through the code to describe the method of computing and networking infrastructure, makes the design of the I can safely and quickly build and replace by the new configuration of the server, the server can have a higher consistency between reduced in “my work environment and your environment does not work”, It also provides better support for subsequent release strategy and operation and maintenance.

Due to the introduction of Docker, different microservices can use different technical architectures, such as Node.js, Java, Ruby, Python and so on. These single services can independently complete the delivery life cycle, as follows:

Microservices case

Netflix’s microservice architecture is as follows, focusing on global distribution with high scalability and availability:

Twitter’s microservices architecture, focusing on efficient and scalable data centers:

———————————————————————————————————————— ————————————————-

Java Architecture Group 650385180 provides a platform for communication and discussion



I hope it will be helpful to your system architecture, software project development, operation and maintenance management, system architecture and R&D management system, information security, enterprise informatization, etc.