什么是微服務

微服務是一種應用架構(gòu)，它將每個應用功能都放在自己的服務中，與其他服務隔離。這些服務是松散耦合的，可獨立部署。

這種架構(gòu)的出現(xiàn)是為了解決舊的 Web 應用開發(fā)的單體方法。在單體軟件中，所有的東西都是作為一個單元構(gòu)建的，所有的業(yè)務邏輯都被歸入一個廣泛的應用。

這種方法使更新代碼庫的過程變得復雜化，因為它影響到整個系統(tǒng)，即使是最小的代碼改動也需要構(gòu)建和部署整個軟件的新版本。此外，哪怕你只想擴展應用的某個特定功能，卻需要擴展整個應用來實現(xiàn)它。

微服務解決了單體系統(tǒng)所面臨的這些挑戰(zhàn)，它將應用從一個整體分割成幾個小部分。

什么時候應該使用微服務？

從本質(zhì)上講，微服務架構(gòu)解決了龐大、復雜應用的快速開發(fā)問題。

對于“哪個更好?”這一問題，目前還沒有通用的答案。答案取決于各種情況，因為每一種情況都有其好處和缺點。

下面是一些微服務架構(gòu)的優(yōu)點和缺點，你可能對此已經(jīng)有所了解：

優(yōu)點

• 語言不可知性：微服務并不限于特定的編程語言，每個微服務都可以用不同的語言來編寫，以支持選定的通信協(xié)議。
• 可擴展性：由于微服務和它的職責可以由開發(fā)者共同承擔，所以如果有一個大的團隊參與到這個項目中，應用就會變得更加易于維護。
• 無限迭代：由于開發(fā)者不會被其他組件所束縛，所以在微服務上迭代會變得更加簡單。
• 單元測試：由于微服務是獨立的應用，它的重點是特定的功能，因此，開發(fā)者可以很輕松地編寫測試腳本，以驗證該特定功能。

缺點

要作為一個整體來管理是很困難的：凱撒大帝有一句名言“分而治之”(divide et impera，拉丁語)，即使在這里也可以大規(guī)模應用，但是要謹慎，因為過多的活動部分會變得難以管理。

• 難以追蹤：如果架構(gòu)變得過于復雜，微服務之間的通信渠道會非常多，出現(xiàn)錯誤后會很難追溯并確定故障點。
• 需要大量的專業(yè)知識：構(gòu)建和部署微服務要求非常高的計劃和協(xié)調(diào)方面的軟技能。
• 具有挑戰(zhàn)性的測試：測試是一把雙刃劍，因為微服務作為一個整體更難測試。集成和端到端的測試同樣會有挑戰(zhàn)。
• 審計日志：可能更難獲得和調(diào)查。

在架構(gòu)方面，SaaS 微服務非常適合，因為微服務是 SaaS 應用的一個不錯的選擇。由于這類應用想要用戶付錢買單，那么它就需要提供高可用的服務，因此將軟件分成小塊可以加快恢復速度。同時，SaaS 應用的發(fā)展主要是由其社區(qū)推動，所以，它也會受到很多變化的影響，而通過微服務和解耦，開發(fā)者可以獲得了靈活性，這是單體架構(gòu)無法提供的。

單體應用程序可能難以水平擴展，因為你必須復制整個應用程序，如果它依賴于單個數(shù)據(jù)庫，這個過程將變得更加困難。另一邊，微服務卻可以根據(jù)單個服務進行擴展、復制或負載平衡。比如，如果你需要發(fā)送更多的電子郵件，你只需要擴展負責電子郵件功能的微服務。今天你有 10 個用戶，明天你有 1000 個;SaaS 應用可以在短時間內(nèi)維持大規(guī)模的增長，這就是為什么他們的架構(gòu)必須要以最經(jīng)濟的方式進行輕松擴展的原因。

這樣還可以減少資源的消耗，因此可以減少賬單。所以，可以肯定地說，微服務是 SaaS 企業(yè)架構(gòu)的下一個階段。

弄清你是否需要微服務的最好方法是問自己：我有關于單體應用的問題嗎?如果有的話，或許你應該考慮轉(zhuǎn)向微服務。如果沒有，那就堅持下去——沒有必要把時間花在一個根本不存在的問題上。

微服務通信是如何工作的？

由于服務之間彼此獨立，所以與微服務的通信需要好好選擇。通信協(xié)議的使用不當會造成應用的性能下降，大家必須根據(jù)自己應用的具體需求來選擇通信協(xié)議。

有兩種通信方式可以選擇：同步通信和異步通信，這是請求 - 響應和基于事件的模式的基礎。

在第一種情況下，即同步方式，客戶端發(fā)送請求并等待響應。這種方法有一個缺陷，那就是它是一個阻塞模式。但是，如果你有一個讀操作非常多的應用時，那就不一定了，因為你的應用更傾向從外部讀取和接受信息。在這種情況下，使用同步方式可能是一個很好的選擇，特別是當它涉及實時數(shù)據(jù)時。

我們的另一個選擇是異步通信，這是一個非阻塞模式。如果你想要一種有彈性的微服務，那么，與同步通信相比，異步通信是一種更好的選擇。在這種情況下，客戶端會發(fā)送一個請求，收到請求的確認，并將其遺忘。這種方法最適用于大量寫操作、無法承受數(shù)據(jù)記錄丟失的應用。

下面是一些涉及微服務通信的解決方案，你可以從中選擇：

• 基于 HTTP 的 REST
• 基于 HTTP/2 的 REST
• WebSocket
• TCP 套接字
• UDP 數(shù)據(jù)包

好好考慮最適合自身需求的通信協(xié)議，因為這將使應用響應更快、效率更高。

為什么 NodeJS 用于微服務？

在構(gòu)建微服務時，有很多頂級編程語言可供選擇。NodeJS 就是其中之一。那么，為什么 NodeJS 是最佳選擇呢?

• 單線程 & 異步：NodeJS 使用事件循環(huán)來執(zhí)行代碼，允許異步代碼被執(zhí)行，從而使服務器能夠使用非阻塞機制來響應。
• 事件驅(qū)動：NodeJS 使用事件驅(qū)動架構(gòu)，該架構(gòu)建立在軟件開發(fā)的常見模式上，被稱為發(fā)布 - 訂閱或觀察者模式，能夠構(gòu)建強大的應用，尤其是實時應用。
• 快速和高度的可擴展性：運行環(huán)境建立在最強大的 JavaScript 引擎之一 V8 JavaScript Engine 之上，因此代碼執(zhí)行速度快，使得服務器能夠同時處理多達 10000 個并發(fā)請求。
• 易于開發(fā)：創(chuàng)建多個微服務會導致重復的代碼。Node.js 的微服務框架很容易創(chuàng)建，因為它抽象了大部分的底層系統(tǒng)。所以用這種編程語言創(chuàng)建一個微服務可以像寫幾行代碼一樣簡單。

實施微服務架構(gòu)

我們從創(chuàng)建用于用戶管理的微服務開始，它將使用 TCP 數(shù)據(jù)包進行通信，并負責對用戶進行 CRUD 操作。我們將使用 PacketSender 對其進行測試，PacketSender 是一個免費的工具，用于發(fā)送支持 TCP 的網(wǎng)絡數(shù)據(jù)包。

微服務的架構(gòu)和作用域被進一步界定。因此，從演示的角度來看，通過 HTTP 實現(xiàn)一個微服務與實現(xiàn) NodeJS API 沒有什么不同。

同時，通過 HTTP 來使用 REST 也很容易，但如果從這個協(xié)議切換到其他協(xié)議時，會出現(xiàn)一些問題。這也是本文中我們將會使用 TCP 包的異步模式來與微服務通信的原因。

我們將使用 NestJS 作為應用的框架。它并非 NodeJS 微服務框架，而是一個用于構(gòu)建服務器端應用的框架。但是，由于其內(nèi)置了多個微服務特性，使得工作變得更加容易。

步驟一：微服務設置

用 Node.js 構(gòu)建微服務相當容易，尤其是用 NestJS 框架。開始時，可以使用 CLI 創(chuàng)建一個新的 NestJS 應用，使用如下命令：

npx @nestjs/cli new user-microservice

該命令會創(chuàng)建并初始化一個新項目。要開始構(gòu)建一個微服務，你需要安裝以下軟件包：

npm i --save @nestjs/microservices

最后，為了讓微服務啟動和運行，我們需要用以下內(nèi)容更新 main.ts 文件：

import { INestMicroservice } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';
import { Transport } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  const microservicesOptions: any = {
    transport: Transport.TCP,
    options: {
      host: '127.0.0.1',
      port: 8875,
    },
  };

  const app: INestMicroservice = await NestFactory.createMicroservice(
    AppModule,
    microservicesOptions,
  );

  app.listen(() => console.log('Microservice is listening'));
}
bootstrap();

NestJS 支持幾個內(nèi)置的傳輸層實現(xiàn)，稱為傳輸器。上面的代碼將創(chuàng)建一個微服務，通過 TCP 傳輸層綁定到本地機器的 8875 端口進行通信。

步驟 2：微服務監(jiān)聽消息

我們可以使用消息模式或事件模式來與微服務通信。

消息模式的作用就像一個請求 - 響應方法，它適用于在服務之間交換消息，而當你只想發(fā)布事件而不等待響應時，就可以使用事件模式。

在我們的案例中，我們只實現(xiàn)根據(jù)給定的輸入創(chuàng)建一個用戶的功能，并且將獲得創(chuàng)建的用戶。因此，我們將在 app.controller.ts 文件中注冊一個名為 create_user 的消息模式。

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @MessagePattern('create_user')
  async createUser(@Payload() payload: CreateUserDto) {
    const user = await this.appService.createUser(payload);
    return user;
  }
}

我們抽象出創(chuàng)建新用戶的邏輯，因為它可以根據(jù)需求和使用的數(shù)據(jù)庫以各種方式實現(xiàn)，我們將只關注與微服務相關的主題。

我們用來創(chuàng)建一個新用戶的有效負載有以下格式：

import { IsString, IsEmail } from 'class-validator';

export class CreateUserDto {
  @IsEmail()
  email: string;
 
  @IsString()
  password: string;
}

一個帶有 email 和 password 的簡單對象

步驟 3：測試微服務

為了測試這個微服務，我們將使用 PacketSender 向應用發(fā)送一個 TCP 包。為此，將地址和端口設置為 127.0.0.1:8875，并從右側(cè)的下拉菜單中選擇 TCP。要對我們的信息進行編碼，請使用 ASCII 字段，并用以下值來完成：

122#{"pattern":"create_user",
"data":{"email":"d@gmail.com","password":"12345678"},
"id":"ce51ebd3-32b1-4ae6-b7ef-e018126c4cc4"}

pattern：是我們正在尋找的信息，create_user。

data：是我們要發(fā)送的 JSON 對象，一個帶有 email 和 password 的對象。

值 122 代表我們的消息的長度，從第一個大括號開始到最后一個大括號(包括兩個)。

數(shù)據(jù)包發(fā)送器配置

如果我們點擊 Send 按鈕，我們會看到如下日志：

日志活動

第二個是我們發(fā)送給微服務的內(nèi)容，第一個是我們收到的內(nèi)容。里面的響應是由我們的微服務返回的對象，即被創(chuàng)建的用戶。

步驟 4：API 網(wǎng)關

現(xiàn)在我們有了微服務，并進行了快速測試，看它是否能接收請求并返回響應，現(xiàn)在是時候創(chuàng)建一個 API 網(wǎng)關并將其連接到微服務上了。

為此，我們將使用上面描述的相同步驟創(chuàng)建一個新的 NestJS 應用，然后用以下內(nèi)容更新 app.module.ts 文件。

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ConfigService } from "./config/config.service";

@Module({
  imports: [],
  controllers: [AppController],
  providers: [
    {
      provide: 'USER_MICROSERVICE',
      useFactory: (configService: ConfigService) => {
        const options = {
          transport: Transport.TCP,
          options: {
            host: configService.get('USERS_MICROSERVICE_HOST'),
            port: Number(configService.get('USERS_MICROSERVICE_PORT')),
          },
        };
        return ClientProxyFactory.create(options as ClientOptions);
      },
      inject: [ConfigService],
    },
    AppService,
  ],
})
export class AppModule {}

我們將使用 .env 文件，我們將在其中存儲任何與配置有關的值。這些文件將在一個配置服務的幫助下被讀取。該微服務可以在 host 127.0.0.1:8875 處找到，其中 port 為 8875。

通過上面的代碼，我們使用 ClientProxy 注入一個新的對象，代表與我們的用戶 - 微服務的連接。這個 NestJS 類提供了幾個內(nèi)置的工具來與遠程微服務交換信息。

為了使用這個鏈接對象，我們可以在 AppController 或 AppService 中注入它，如下所示：

@Controller()
export class AppController {
  constructor(
    @Inject('USER_MICROSERVICE') private readonly client: ClientProxy,
    private readonly appService: AppService
  ) {}

  @Post('create-user')
  async createUser(@Body() payload: CreateUserDto) {
    return this.client.send('create_user', payload).toPromise();
  }
}

現(xiàn)在，每次 API 在路由 create-user 處受到 POST 請求時，API 網(wǎng)關將把請求和有效載荷一起轉(zhuǎn)發(fā)給微服務，然后從微服務返回響應給用戶。