閱讀本文大約需要 6 分鐘

概述

• 前言
• 什麼是微服務
• 微服務的特征與優勢
• 微服務的不足
• 微服務通信方式
• 我應該使用微服務嗎？
• 後記

前言

大半年前，我第一次聽說【微服務】這個詞，當時由于好奇心，就 Google 了一下這個詞，從此埋下了一顆學習微服務的心。在前半年的時間裡因為忙，所以抽不出完整的時間塊來學習微服務。但都有使用閑碎的時間來看相關的概念與架構。最近總算是有點時間了，我覺得光看概念是沒有用的，要真真實實地實踐一下，才能真正學到東西。這才有了這篇文章（後面會有系列文章）。

什麼是微服務

我們就以微信為栗子，來解釋一下微服務。首先假設你要做一款簡化版的微信産品，他隻有如下幾個功能。那麼你的初期系統設計應該是這樣的：

微信單體架構

随着時間的遷移，我們日子來到了 2019.01.01 00:00 跨年，此時此刻，很多人都在發朋友圈。朋友圈接口訪問量很大很大很大，服務器訪問峰值瞬間沖頂，那麼我們可以開始做集群操作。也就是整一個服務器做集群操作。那麼我們的注冊登錄接口、支付接口、聊天接口也有了一個複制集，在此時此刻這幾個接口是比較雞肋的，沒有很大的訪問量，那我們能不能隻将朋友圈的接口做擴容呢？答案當然是可以的，且看下圖 -- 微服務架構

微信微服務架構

那麼當我們微服務架構遇到 2019.01.01 00:00 跨年，會怎麼樣呢？

直接水平擴展朋友圈服務，如下圖，峰值壓力有所緩解。

微信微服務架構

然而在各個功能拆解成一個個的服務之後，由客戶端直接訪問各個微服務，這樣就直接将我們的服務暴露了出來，客戶端也需要定制相應的訪問策略。這樣的設計還是沒有那麼友好。那麼，我們能不能将所有微服務統一到一起呢？且看下圖：

微信微服務架構plus

在這張示例圖中，多了一個 APIGateway 模塊，那 API 網關是用來幹嘛的呢？

一般情況下 API 網關有以下任務：路由，安全，限流，緩存，日志，監控，重試，熔斷等，然後服務層就純粹的做業務，也能夠很好的保證業務代碼的幹淨，不用關心安全，壓力等方面的問題。

當然，以上示例圖隻是一個小小的演示，真實的使用中，要比這個複雜得多，這裡隻是先抛出概念，供大家理解。

維基百科對微服務的定義:

微服務 (Microservices) 是一種軟件架構風格，它是以專注于單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。

微服務的特征與優勢

微服務特征：

1. 單一職責；
2. 輕量級的通信；
3. 隔離性，運行在自己的進程中，不會相互幹擾；
4. 有自己的數據，數據的獨立性，每個微服務都有自己的數據庫；
5. 技術的多樣性，選用适合的技術做合适的事；
6. 一個微服務就負責某一個職責，就像朋友圈服務，它就隻負責朋友圈的【增删查】功能，與其他服務獨立開來，可以選用不同的技術語言，來滿足不同的需求。

微服務的優勢：

• 獨立性
• 每個微服務的構建、部署、擴容、縮容、數據庫都是獨立的。數據庫表修改時，互補影響。
• 敏捷性
• 功能單一、可快速添加新需求
• 技術棧靈活
• 可以發揮不同語言的優勢，例如：用 Python 來爬數據，nodejs 來處理 io 流
• 高效團隊
• 可以分發給不同的團隊進行開發

微服務的不足

1. 額外的工作；
2. 數據一緻性；
3. 溝通成本；
4. debug 單元測試困難；
5. 需要額外工作，例如：服務的拆分（即如何拆分微服務，哪些服務應該拆到一起）、服務注冊、服務發現、微服務間的通信。每個微服務都持有獨立的數據庫，無法做到數據強一緻性，隻能做到最終結果一緻性。做微服務也會增加團隊的溝通成本。

微服務通信方式

微服務可以使用兩種基本消息傳遞模式 -- 同步與異步消息傳遞，來與其他微服務通信。

1. 同步通信。 在此模式下，一個服務使用 HTTP 或 RPC（Remote Procedure Call，翻譯過來為“遠程過程調用”） 框架等協議調用另一個服務公開的 API。 此選項之所以稱作同步消息傳遞模式，是因為調用方需要等待接收方返回的響應。比較通用的 RPC 框架有：gRPC（Google）、Thrift（Apache）
2. 異步消息傳遞。 在此模式下，服務可以在不等待回應的情況下發送消息，然後一個或多個服務以異步方式處理該消息。比較流行的消息隊列有：RabbitMQ、ZeroMQ、Kafka、ActiveMQ
3. 至于具體怎麼通信，後面會有詳細的分享。本文隻是先介紹微服務如何通信。

我們應該使用微服務嗎？

微服務已經成為一種熱門的架構模式了，打開各大技術類網站幾乎都少不了微服務的身影。但微服務真的适合我們當下的用戶規模與公司級别嗎？這個問題，其實也沒有比較統一的答案。在我看來，其實大部分小公司是用不到微服務的，因為其不足遠大于其優勢，單體應用做好優化、數據庫讀寫分離、集群、負載均衡，就能應對日常的流量。當你以上的優化都做了，還是撐不住壓力的話，就可以考慮微服務了。當然，服務架構選型還是看不同情況和公司意志的，如果有必要做跨語言等其他需求，那就做微服務的。

後記

最後，抛開業務上的原因，我們作為技術人也需要學習微服務相關的技術，不能局限于用不上就不學習。在當下大環境下，儲備多一點知識，提高自身競争力總是沒有壞處的。

個人的知識儲備總是有限的，如有錯誤的地方，還請大佬斧正。點擊閱讀原文，鍊接到我的知乎，我會在知乎上對文章錯誤的地方進行修改。

往期推薦：

秋招季，用Python分析深圳程序員工資有多高？

用Python告訴你深圳房租有多高

我在這幾款學習利器中學到很多

---

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部