Microservice Architecture 简明教程

Microservice Architecture - Introduction

微服务是一种基于服务的应用程序开发方法。此方法中，大型应用程序将被划分为最小的独立服务单元。微服务是通过将整个应用程序划分为一系列相互关联的服务来实现面向服务架构（SOA）的过程，其中每个服务只满足一项业务需求。

Microservice is a service-based application development methodology. In this methodology, big applications will be divided into smallest independent service units. Microservice is the process of implementing Service-oriented Architecture (SOA) by dividing the entire application as a collection of interconnected services, where each service will serve only one business need.

The Concept of Going Micro

在面向服务架构中，整个软件包将被细分为小的、相互关联的业务单元。每个这些小的业务单元将使用不同的协议互相通信，以向客户交付成功的业务。现在的问题是，微服务架构（MSA）与 SOA 有什么不同？一句话来说，SOA 是一种设计模式，微服务是实现 SOA 的实现方法，或者我们可以说微服务是 SOA 的一种类型。

In a service-oriented architecture, entire software packages will be sub-divided into small, interconnected business units. Each of these small business units will communicate to each other using different protocols to deliver successful business to the client. Now the question is, how Microservice Architecture (MSA) differs from SOA? In one word, SOA is a designing pattern and Microservice is an implementation methodology to implement SOA or we can say Microservice is a type of SOA.

以下是开发以微服务为导向的应用程序时需要记住的一些规则。

Following are some rules that we need to keep in mind while developing a Microservice-oriented application.

  1. Independent − Each microservice should be independently deployable.

  2. Coupling − All microservices should be loosely coupled with one another such that changes in one will not affect the other.

  3. Business Goal − Each service unit of the entire application should be the smallest and capable of delivering one specific business goal.

让我们考虑一个在线购物门户的例子，以深入了解微服务。现在让我们将整个电子商务门户分解为小型业务单元，例如用户管理、订单管理、入住、支付管理、配送管理等。一笔成功的订单需要在特定时间范围内历经所有这些模块。以下是与电子商务系统相关的不同业务单元的合并图像。

Let us consider an example of online shopping portal to understand microservice in depth. Now, let us break this entire E-commerce portal into small business units such as user management, order management, check-in, payment management, delivery management, etc. One successful order needs to proceed through all of these modules within a specific time frame. Following is the consolidated image of different business units associated with one electronic commerce system.

electronic commerce solutions

这些业务模块中的每一个都应该有自己的业务逻辑和利益相关者。它们与其他第三方供应商软件进行通信以满足某些特定需求，并且彼此之间也进行通信。例如，订单管理可能会与用户管理进行通信以获取用户信息。

Each of these business modules should have its own business logic and stakeholders. They communicate with other third party vendor softwares for some specific needs, and also with each other. For example, order management may communicate with user management to get user information.

现在，考虑到您正在运行包含前面提到的所有业务单元的在线购物门户，您确实需要一个由前端、后端、数据库等不同层组成的企业级应用程序。如果您的应用程序没有进行扩展并在一个单独的 war 文件中得到完全开发，那么它将被称为典型的单体应用程序。据 IBM 所述，典型的单体应用程序在内部应具有以下模块结构，其中只有一个端点或应用程序负责处理所有用户请求。

Now, considering you are running an online shopping portal with all of these business units mentioned earlier, you do need some enterprise level application consisting of different layers such as front-end, back-end, database, etc. If your application is not scaled and completely developed in one single war file, then it will be called as a typical monolithic application. According to IBM, a typical monolithic application should possess the following module structure internally where only one endpoint or application will be responsible to handle all user requests.

database

在上面的图像中，您可以看到用于存储不同用户和业务数据的不同模块，例如数据库。在前端，我们有不同的设备，我们通常在那里呈现用户或业务数据以供使用。在中间，我们有一个包可以是可部署的 EAR 或 WAR 文件，它接受用户末端的请求，借助于资源对其进行处理，然后将其呈现在用户面前。在业务需要对上述范例进行任何更改之前，一切都很好。

In the above image, you can see different modules such as Database for storing different users and business data. At the front-end, we have different device where we usually render user or business data to use. In the middle, we have one package that can be a deployable EAR or WAR file that accepts request form the users end, processes it with the help of the resources, and renders it back to the users. Everything will be fine until business wants any changes in the above example.

考虑以下情况，您必须根据业务需求更改应用程序。

Consider the following scenarios where you have to change your application according to the business needs.

业务单元需要对“搜索”模块进行一些更改。然后，您需要更改整个搜索过程并重新部署应用程序。在这种情况下，您正在重新部署其他单元而根本没有进行任何更改。

Business unit needs some changes in the “Search” module. Then, you need to change the entire search process and redeploy your application. In that case, you are redeploying your other units without any changes at all.

business unit

现在，您的业务部门需要对“签出”模块进行一些更改以包括“钱包”选项。您现在必须更改“签出”模块并将它重新部署到服务器中。请注意，您正在重新部署软件包的不同模块，而我们并没有对其进行任何更改。这就是面向服务的架构，更具体地说是微服务架构的概念的由来。我们可以以这种方式开发单体应用程序，使得软件的每个模块都充当独立的单元，能够独立地处理单个业务任务。

Now again your business unit needs some changes in “Check out” module to include “wallet” option. You now have to change your “Check out” module and redeploy the same into the server. Note, you are redeploying the different modules of your software packages, whereas we have not made any changes to it. Here comes the concept of service-oriented architecture more specific to Microservice architecture. We can develop our monolithic application in such a manner that each and every module of the software will behave as an independent unit, capable of handling a single business task independently.

考虑以下示例。

Consider the following example.

在上述架构中，我们不会创建包含端到端紧凑服务的任何 ear 文件。相反，我们通过将它们作为服务公开来划分软件的不同部分。软件的任何部分都可以通过使用各自的服务来轻松地彼此进行通信。这就是微服务在现代 Web 应用程序中扮演重要角色的方式。

In the above architecture, we are not creating any ear file with compact end-to-end service. Instead, we are dividing different parts of the software by exposing them as a service. Any part of the software can easily communicate with each other by consuming respective services. That’s how microservice plays a great role in modern web application.

让我们在微服务的意义上比较我们的购物车示例。我们可以将购物车分解为不同的模块，例如“搜索”、“筛选”、“签出”、“购物车”、“推荐”等。如果我们想构建一个购物车门户，那么我们必须构建上述模块，使其能够彼此连接，以提供 24x7 良好的购物体验。

Let us compare our shopping cart example in the line of microservice. We can break down our shopping cart in the different modules such as “Search”, ”Filter”, “Checkout”, “Cart”, “Recommendation”, etc. If we want to build a shopping cart portal then we have to build the above-mentioned modules in such a manner that they can connect to each other to give you a 24x7 good shopping experience.

Advantages & Disadvantages

以下是一些使用微服务而非使用单体应用程序的优势：

Following are some points on the advantages of using microservice instead of using a monolithic application.

Advantages

  1. Small in size − Microservices is an implementation of SOA design pattern. It is recommended to keep your service as much as you can. Basically, a service should not perform more than one business task, hence it will be obviously small in size and easy to maintain than any other monolithic application.

  2. Focused − As mentioned earlier, each microservice is designed to deliver only one business task. While designing a microservice, the architect should be concerned about the focal point of the service, which is its deliverable. By definition, one microservice should be full stack in nature and should be committed to delivering only one business property.

  3. Autonomous − Each microservice should be an autonomous business unit of the entire application. Hence, the application becomes more loosely coupled, which helps to reduce the maintenance cost.

  4. Technology heterogeneity − Microservice supports different technologies to communicate with each other in one business unit, which helps the developers to use the correct technology at the correct place. By implementing a heterogeneous system, one can obtain maximum security, speed and a scalable system.

  5. Resilience − Resilience is a property of isolating a software unit. Microservice follows high level of resilience in building methodology, hence whenever one unit fails it does not impact the entire business. Resilience is another property which implements highly scalable and less coupled system.

  6. Ease of deployment − As the entire application is sub-divided into small piece of units, every component should be full stack in nature. All of them can be deployed in any environment very easily with less time complexity unlike other monolithic applications of the same kind.

以下是有关微服务架构缺点的一些要点。

Following are some points on the disadvantages of microservice architecture.

Disadvantages

  1. Distributed system − Due to technical heterogeneity, different technologies will be used to develop different parts of a microservice. A huge set of skilled professionals are required to support this big heterogeneous distributed software. Hence, distributed and heterogeneity stands as a number one disadvantage of using microservice.

  2. Cost − Microservice is costly, as you have to maintain different server space for different business tasks.

  3. Enterprise readiness − Microservice architecture can be considered as a conglomerate of different technologies, as technology is evolving day-by-day. Hence, it is quite difficult to make a microservice application enterprise ready to compare to conventional software development model.

Microservice Over SOA

下表列出了 SOA 和微服务的某些特性，展示了与 SOA 相比使用微服务的重要性。

The following table lists certain features of SOA and Microservice, bringing out the importance of using microservice over SOA.

Component

SOA

Microservice

Design pattern

SOA is a design paradigm for computer software, where software components are exposed to the outer world for usage in the form of services.

Micro Service is a part of SOA. It is a specialized implementation of SOA.

Dependency

Business units are dependent on each other.

All business units are independent of each other.

Size

Software size is bigger than the conventional software.

Software size is small.

Technology

Technology stack is less than Microservice.

Microservice is heterogeneous in nature as exact technologies are used to perform a specific task. Microservices can be considered as a conglomerate of many technologies.

Autonomous and Focus

SOA applications are built to perform multiple business tasks.

Microservice applications are built to perform a single business task.

Nature

Monolithic in nature.

Full stack in nature.

Deployment

Deployment is time-consuming.

Deployment is very easy. Hence, it will be less time-consuming.

Cost-effectiveness

More cost-effective.

Less cost-effective.

Scalability

Less compared to Microservices.

Fully scaled.

Example

Let us consider one online CAB booking application. If we want to build that application using SOA, then its software units will be − GetPayments And DriverInformation And MappingDataAPIAuthenticateUsersAnd DriversAPI

If the same application is built using microservice architecture, then its APIs will be − SubmitPaymentsServiceGetDriverInfoServiceGetMappingDataServiceAuthenticateUserServiceAuthenticateDriverService