"Architecture" microservices Combat: From publishing to architecture--Next

maxleap 2016-03-25 13:53

The previous article introduced the differences between microservices and monomer architectures, the design of microservices, messaging, inter-service communication, and data-centric, and this article will continue in-depth microservices to introduce other features.

Governance to be centralized

Usually "governance" means building a plan and forcing people to achieve the goals of the organization by working hard. SOA governance guides developers in developing reusable services, and how services should be designed and developed over time. Governance establishes a service agreement between service providers and consumers, telling consumers what kind of support they can get from service delivery.

There are two common types of governance in SOA:

• Design-time governance-define and control the implementation of service creation, design, and service policies.

• Governance at runtime-ensures that policies are executed.

So what does it mean to govern in a micro-service?

In microservices architectures, different microservices are independent of each other and are based on different platforms and technologies. Therefore, there is no need to define a common standard for the design and development of services.

Summarize the governance of microservices to be centralized as follows:

• MicroServices architectures that do not need to focus on governance at design time.

• Each microservices can have independent design and execution decisions.

• The MicroServices architecture focuses on developing generic/reusable services.

• runtime governance, such as security level assurance (SLA), throttling, monitoring, security, and service discovery, can be handled at the API Gateway layer.

Service Registration and Discovery

Micro-service architecture, there are a large number of micro-services need to deal with. Because of the rapid and agile development of microservices, their locations may change dynamically. As a result, when the runtime needs to be able to discover where the service is located, service discovery can solve the problem.

Service Registration

The registry has instances and location information for microservices, and the microservices register their information with the registry at startup, and log off when it is closed. Other users are able to find available microservices and related information through the registration center.

Service discovery

In order to find available services and their location information, a service discovery mechanism is required. There are two discovery mechanisms, client discovery and server discovery.

Client Discovery-Client or API gateway by querying the service registry or service location information.

Figure 9: Client Discovery

The client/api gateway must invoke the Service registry component to implement the logic of service discovery.

Server-side Discovery-a client/api gateway sends a request to a component of known location information (such as a load balancer). Component to access the registry to find the location information for the microservices.

Figure 10: Server discovery

Similar to Kubernetes (http://kubernetes.io/v1.1/docs/user-guide/services.html), this microservices deployment solution provides a server-side Autodiscover mechanism.

Deployment

The way microservices are deployed is also particularly important, and the following are key:

• Ability to publish or unpublish independently of other microservices

• MicroServices can scale horizontally (one service is larger than other requests)

• Build and publish quickly

• The functionality between microservices does not affect each other

Docker (a Linux-and open-source application that helps develop and operate applications in containers) enables rapid deployment of microservices, including key points:

• Package microservices into Docker images

• Launch Container Instance

• Changing the number of instances to meet capacity expansion requirements

The use of Docker containers to build, publish, and start microservices can be very fast compared to traditional virtual machine models.

With the ability to further expand Docker, kubernetes can scale from a single Linux host to a Linux cluster, support multiple hosts, manage container locations, service discovery, and multiple instances. are important features of microservices requirements. Therefore, it is a very powerful solution to use kubernetes to manage the distribution of microservices and containers.

Figure 11: Container for building and deploying services

Figure 11 shows a micro-service deployment for retail applications. Each service is in a separate container with two containers per host, and the number of containers can be arbitrarily adjusted by kubernetes.

Safety

In the actual operating environment, the security of microservices is also very important. Let's look at how security is implemented under the monolithic architecture.

A typical monomer application, security issues are mainly "who calls", "what the caller can do", "how to handle". Once the server receives the request, it is generally at the beginning of the processing chain, with security components to secure the requested information.

Can we apply this approach directly to the microservices architecture? The answer is yes, need to buy a micro-service to implement a security component from the Resource center to obtain the corresponding user information to achieve security control. This is the more elementary way of handling. You can try some standard API methods, such as OAuth2 and OpenID. Before delving into the study, you can summarize the two security protocols and how to use them.

Oauth2-is an access-delegation agreement. A client that needs permission to request an access token from the authorization service. The access token does not have any information about the user/client, just a user reference information that is used by the authorization server. Therefore, there is no security issue with this "referenced token".

OpenID is similar to OAuth, but the authorization server also issues an ID token that contains user information in addition to the access token. It is usually implemented by the authorization server in the form of JWT (JSON Web Token). In this way, customers and server-side trust are ensured. A JWT token is a "content-aware token" that contains the user's identity information and is unsafe to use in a public environment.

Now let's look at how these protocols can be used in web retail sites to secure microservices.

Figure 12: Resolving security issues with OAuth2 and OpenID

The key steps to implementing MicroServices security are shown in Figure 12:

• All authorizations are implemented by the authorization server via OAuth and OpenID, ensuring that users have access to the correct data.

• With the API gateway approach, all client requests have a unique entry.

• The client obtains an access token from the authorization server and sends the token to the API gateway.

• Tokens are processed by the gateway-the API Gateway gets a token and is sent to the authorization server to obtain a JWT.

• The gateway sends the JWT and the request to the microservices.

The JWT contains the necessary user information, and if each microservices can resolve the JWT, then each service in your system can handle the identity-related business. In each microservices, you can have a lightweight component that handles JWT.

Transaction

How do you support transactions in MicroServices? In fact, distributed transaction support across multiple microservices is very complex, and microservices are designed to avoid transactional operations between multiple services as much as possible.

The solution is that microservices are designed to follow functional self-contained and single-responsibility principles. Supporting distributed transactions across multiple microservices is not a good design idea in a microservices architecture, and it is often necessary to re-demarcate the responsibilities of microservices. In some scenarios, you must support distributed transactions across services, and you can take advantage of "combined operations" within each microservices.

The most critical thing is to design microservices based on the principle of single responsibility, which is problematic if a service fails to perform certain operations properly. Then upstream operations are required to perform rollback operations in their respective microservices.

Fault Tolerant Design

Compared with the design of the monomer, the MicroServices architecture introduces more services, which increases the likelihood of errors at each service level. A service may fail due to various problems such as network problems, underlying resources, and so on. The impossibility of a service should not affect the crash of the entire application. Therefore, the microservices system must be fault-tolerant, or even auto-reply, with no perception of the client.

Any service may have problems at any time, and the monitoring system needs to be able to detect issues and recover automatically. There are many common patterns in the microservices environment.

Line interruption

After the failure rate of the request in the microservices reaches a certain level, the monitoring in the system can activate the line interruption. When the number of normal requests is restored to a certain extent, the switch of the line interruption is turned off, and the system reverts to the normal state.

This mode can avoid unnecessary resource consumption, the request processing delay will lead to time-out, so as to improve the monitoring system.

Firewall

One application will have many microservices to hire, and the failure of a single microservices should not affect the entire system. Firewall mode emphasizes the direct isolation of services, and microservices are not affected by other microservices failures.

Processing timeout

The timeout mechanism is to proactively abandon the response that waits for a microservices when it determines that no more responses are available. This timeout should be configurable.

In what cases, how do you use these patterns? In most cases, it should be handled at the gateway. When a microservices is unavailable or does not respond, the gateway can decide whether to perform a line break or a startup timeout mechanism. The firewall mechanism is equally important, the gateway is the only entry for all requests, and a microservices failure should not affect other microservices. The gateway is also the center of Access to micro-service status and monitoring information.

Micro-services, enterprise integration, API management

We have discussed the architecture and features of microservices and how to apply them in a modern IT system. It is also necessary to realize that microservices are not a panacea for all problems. The blind pursuit of popular technical concepts does not solve the problem of enterprise IT systems.

MicroServices have many advantages, but micro-services alone do not solve all the problems in enterprise it. For example, microservices require the removal of an ESB, but in real-world IT systems, a large number of applications and services are based on ESBs rather than microservices. Integration of existing systems requires some integration bus. The reality is that microservices and other enterprise architectures coexist.

Original Kasun Indrasiri, software Architect, WSO2

Original link: https://dzone.com/articles/microservices-in-practice-1

Translated from Maxleap team-Cloud service Development member: Frank Qin

About MAXLEAP

MAXLEAP Mobile cloud Service platform provides enterprises with a one-stop mobile research and Operation Cloud service, which helps enterprises to develop and launch mobile applications quickly, and provides services such as data cloud storage, cloud engine, payment management, IM, data analysis and marketing automation.

MAXLEAP website Link: https://maxleap.cn

If you are learning about mobile research and development and cloud services, you may wish to follow our service number MAXLEAPSVC and we will not regularly push related dry goods. Please look forward to!

Resources:

Micro-service combat: From publishing to architecture--Next:http://toutiao.com/i6265438512984621570/

"Architecture" microservices Combat: From publishing to architecture--Next