"Architecture" micro-service Combat: From publishing to architecture--the previous article

Micro-service Combat: From publishing to architecture--the previous article maxleap 2016-03-23 10:42

"MicroServices" is a very popular term in the field of software architecture and can find many definitions of microservices, guidelines, and articles on how to benefit from microservices, and there are few resources to apply "microservices" in the practice of enterprises. In this article, we describe the basic concepts of the MicroServices architecture (microservices Architecture) and how to apply them in practice.

Monomer Architecture (Monolithic Architecture)

Enterprise-class applications typically face a wide variety of business needs, and the common approach is to accumulate a lot of functionality into the same monolithic architecture. For example: Common ERP, CRM and other systems are operating in a single structure, and because of the provision of a large number of business functions, with the upgrading of functions, the entire development, release, positioning problems, expansion, upgrade such a "monster" system will become more and more difficult.

The initial efficiency of the monomer architecture is high and the application becomes larger over time. In each iteration, the development team faces new features and then develops many new code, and over time, this simple application becomes a huge monster.

Figure 1: Monolithic architecture

Most enterprises solve these problems through SOA, the idea of SOA is to bring together similar functions in the application and provide them in the form of service. So an application based on SOA architecture can be understood as a combination of a batch of services. The problem with SOA is the introduction of a large number of services, message format definitions, and specifications.

In most cases, SOA services are directly independent of each other, but are deployed in the same runtime environment (similar to a Tomcat instance, running many Web applications). Similar to the monolithic architecture, SOA services become more complex as business functions grow, essentially without the benefit of SOA. Figure 1 is an online retail site with a variety of services, all of which are deployed in a running environment and are a typical monolithic architecture.

The application of monomer architecture generally has the following characteristics:

• design, develop, and deploy as a single unit.

• become more complex, resulting in maintenance, upgrades, and new features becoming extremely difficult

• It is difficult to develop and publish in an agile development model

• Partial update, all need to redeploy the entire app

• Horizontal scaling: Must be scaled as an application, scaling becomes difficult when resource requirements conflict (some services require more compute resources, some require more memory resources)

• Availability: A service's instability can lead to an entire application problem

• Innovation difficulties: It is difficult to introduce new technologies and frameworks, all of which are built on homogeneous frameworks

Micro-Service Architecture (MicroServices Architecture)

The core idea of a microservices architecture is that an application is made up of several small, independent, microservices that run in their own processes and are not dependent on development or release.

Most people's definition of microservices is to split services that would otherwise be running in the monolithic architecture into separate services and run in their own processes. In my opinion, not only that. The key point is that different services can be built on different technical architectures based on different business requirements and focused on limited business functions.

As a result, online retail sites can be summarized in the micro-service architecture of Figure 2. Based on business requirements, an account service microservices need to be added, so building microservices is by no means a simple separation of services in a monolithic architecture.

Figure 2: Micro-service architecture

Micro-Service Design: scale, scope, business function

You might build applications from scratch with microservices, or you might refactor existing systems to determine the scale, scope, and functionality of the microservices are particularly important. Let's discuss some of the key issues and misconceptions about microservices design:

• "Micro" can easily be misunderstood: Many developers tend to take the service to the minimum granularity to do

• In the SOA approach, the service is still running as a monolithic architecture to support different functions. If you continue to use Sao similar services, only nominally called microservices, does not bring any micro-service advantage.

So what should we design in microservices? The following are the design guidelines for MicroServices:

• Single Responsibility Principle: Focusing the functionality of one microservices on a specific business or limited scope can contribute to the release of agile development and services.

• The design phase involves defining the scope of the business.

• Need to be concerned with the business scope of microservices, not the number and scale of services as small as possible. Quantity and scale are subject to business functions.

• Unlike SOA, the functionality, operation, and messaging protocols of a microservices are as simple as possible.

• At the beginning of the project, the scope of the service is relatively broad, and with the deepening, further reconstruction of services, subdivision of MicroServices is a good practice.

Micro Service messages

In the monolithic architecture, communication between different functions is through method invocation, or cross-language communication. SOA reduces the direct coupling of this language and employs a SOAP protocol-based Web service. The functionality and message body definitions of this Web service are complex, and microservices require a lighter-weight mechanism.

Sync messages-REST, Thrift

The synchronization message is that the client needs to wait until the server returns an answer. Rest is the default way of synchronizing messages in MicroServices, which provides a simple message format based on the HTTP protocol and resource API style, which is used by most microservices (each function represents a resource and the corresponding action).

Thrift is another alternative. It uses the interface description language to define and create services, supports extensible cross-language service development, and contains code generation engines that can be used in multiple languages such as C + +, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cocoa, Small Talk, etc. create efficient, seamless services that transmit data in a binary format that is smaller in size relative to XML and JSON, and more advantageous for high concurrency, large data volumes, and multi-lingual environments.

Figure 3:rest Interface, external micro-service

Asynchronous messages-AMQP, STOMP, MQTT

The asynchronous message is that the client does not have to wait for the service to answer, and should be notified when it is due. Some microservices require asynchronous messaging, typically using AMQP, STOMP, and MQTT.

Message Format-JSON, XML, Thrift, Protobuf, Avro

Message format is another important factor in microservices. SOA Web services generally take text messages, based on complex message format (SOAP) and message definition (XSD). MicroServices use a simple text protocol JSON and XML, HTTP-based resource API style. If a binary is required, by using the thrift, Protobuf, Avro.

Service contract-Define interfaces-Swagger, RAML, Thrift IDL

If you implement a feature as a service and publish it, you need to define a set of conventions. In the monolithic architecture, SOA is wsdl,wsdl too complex and tightly coupled with soap and not suitable for microservices.

Rest-designed microservices typically use swagger and raml to define conventions.

For microservices that are not based on rest design, such as thrift, the IDL (Interface Definition Languages), such as thrift IDL, is usually used.

Micro-service Integration (inter-service communication)

Under the micro-service architecture, the application services are directly independent of each other. In a specific business application, some mechanisms are needed to support communication between microservices. Therefore, inter-service communication mechanisms are particularly important.

Under the SOA system, services are communicated through the Enterprise service Bus, where many business logic is in the middle tier (message routing, transformation, and organization). The microservices architecture tends to reduce the reliance on the central message bus (similar to ESB) and distribute the business logic across each specific service terminal.

Most microservices are based on standard protocols such as HTTP, JSON, and the integration of different standards and formats becomes less important. Another option is to use a lightweight message bus or gateway with routing capabilities and no complex business logic. Here are a few common architectural approaches.

Point-to-point mode-Invoke service directly

In point-to-point mode, the service is used directly between services. Each microservices open the rest API and invoke the interfaces of other microservices.

Figure 4: Communication by point-to-point mode

Obviously, in a relatively simple microservices scenario, this approach is also feasible, and as the application complexity increases, it becomes increasingly non-maintainable. There are some SOA-like ESBs that try not to use point-to-point integration.

The point-to-point has several drawbacks:

• Non-functional requirements, such as user authorization, throttling, and monitoring, need to be implemented in each micro-service

• As functionality evolves, services become more complex.

• Different services direct, client and service directly without control function (monitoring, tracking, filtering)

• The direct communication in the large-scale system design, is usually the inverse typical.

Therefore, if you design a large micro-service system, try to avoid point-to-point communication, and not like an ESB, such as the heavy-duty bus. Instead, a lightweight bus can provide an abstraction of non-business functions. This is how the API gateway works.

api-Gateway Mode

The core point of the API Gateway approach is that all clients and consumers handle all non-business functions at the gateway layer through a unified Gateway service. Typically, a gateway is also an Access API that provides rest/http. The server registers and manages services through API-GW.

Figure 5: Exposing microservices via the api-gateway

Using our online store example, in Figure 5, all the business interfaces are exposed through the API gateway, which is the only entry for all client interfaces. Communication between MicroServices also passes through the API gateway.

The following advantages are used in Gateway mode:

• Ability to provide gateway-level abstraction for microservices interfaces. For example: The interface of the microservices can be various, at the gateway layer, can expose the unified standard interface externally.

• Light-weight message routing, format conversion.

• Unified control of security, monitoring, current limit and other non-business functions.

• Each microservices becomes lighter, non-business functions are handled uniformly at the gateway layer, and microservices only need to focus on business logic

Currently, the API gateway approach should be the most widely used design pattern in the microservices architecture.

Message Agent Mode

MicroServices can also be integrated in asynchronous scenarios, using queues and subscription topics to implement message publishing and subscriptions. A micro-service can be the publisher of a message that sends the message asynchronously to a queue or to a subscription subject. As a consumer, microservices can get messages from a queue or a topic altogether. The direct call between services is decoupled through the message middleware.

Figure 6: Asynchronous Communication mode

Typically asynchronous producer/consumer patterns, via AMQP, Mqtt, and other asynchronous message specifications.

De-Centering of data

In the monolithic architecture, the service modules of different functions store the data in a central database.

Figure 7: Monolithic architecture that stores all data in a single database

MicroServices, the design of multiple services is independent of each other, and data should be independent of each other (for example, changes in the way a database structure is defined for a microservices, which may disrupt other services). Therefore, each micro-service should have its own database.

Figure 8: Each micro-service has its own private database, and other microservices are not directly accessible.

Key points of the data-centric conversation:

• Each microservices has its own private database to persist business data

• Each micro-service can only access its own database, and cannot access the database of other services

• In some business scenarios, you need to update multiple databases in one transaction. This situation also does not directly access other microservices databases, but through the operation of the micro-service.

Data de-centralized, further reducing the coupling between microservices, different services can use different database technology (SQL, NoSQL, etc.). In complex business scenarios, if multiple microservices are included, they are typically handled on the client or the middle tier (Gateway).

The next article describes the other aspects of microservices: Management de-centering, service registration and discovery, security, transaction, failure design, and others.

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.

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--the previous article:http://toutiao.com/a6263305373991223554/?tt_from=mobile_qq&utm_campaign=client_share& App=news_article&utm_source=mobile_qq&iid=3933520870&utm_medium=toutiao_android

Schema MicroServices Combat: From publish to schema-previous