概述
- 前言
- 什麼是微服務
- 微服務的特徵與優勢
- 微服務的不足
- 微服務通訊方式
- 我應該使用微服務嗎？
- 後記
前言
大半年前，我第一次聽說【微服務】這個詞，當時由於好奇心，就 Google 了一下這個詞，從此埋下了一顆學習微服務的心。在前半年的時間裡因為忙，所以抽不出完整的時間塊來學習微服務。但都有使用閒碎的時間來看相關的概念與架構。最近總算是有點時間了，我覺得光看概念是沒有用的，要真真實實地實踐一下，才能真正學到東西。這才有了這篇文章（後面會有系列文章）。
什麼是微服務
我們就以微信為栗子，來解釋一下微服務。首先假設你要做一款簡化版的微信產品，他只有如下幾個功能。那麼你的初期系統設計應該是這樣的：
隨著時間的遷移，我們日子來到了 2019.01.01 00:00 跨年，此時此刻，很多人都在發朋友圈。朋友圈介面訪問量很大很大很大，伺服器訪問峰值瞬間衝頂，那麼我們可以開始做叢集操作。也就是整一個伺服器做叢集操作。那麼我們的註冊登入介面、支付介面、聊天介面也有了一個複製集，在此時此刻這幾個介面是比較雞肋的，** 那我們能不能只將朋友圈的介面做叢集呢？**答案當然是可以的，且看下圖 -- 微服務架構
當然，以上示例圖只是一個小小的演示，真實的使用中，要比這個複雜得多，這裡只是先丟擲概念，供大家理解。
維基百科對微服務的定義:
微服務 (Microservices) 是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。
微服務的特徵與優勢
微服務特徵：
- 單一職責；
- 輕量級的通訊；
- 隔離性，執行在自己的程式中，不會相互干擾；
- 有自己的資料，資料的獨立性，每個微服務都有自己的資料庫；
- 技術的多樣性，選用適合的技術做合適的事；
一個微服務就負責某一個職責，就像朋友圈服務，它就只負責朋友圈的【增刪查】功能，與其他服務獨立開來
微服務的優勢：
- 獨立性 每個微服務的構建、部署、擴容、縮容、資料庫都是獨立的。資料庫表修改時，互補影響。
- 敏捷性 功能單一、可快速新增新需求
- 技術棧靈活 可以發揮不同語言的優勢，例如：用 python 來爬資料，nodejs 來處理 io 流
- 高效團隊 可以分發給不同的團隊進行開發
微服務的不足
- 額外的工作；
- 資料一致性；
- 溝通成本；
需要額外工作，例如：服務的拆分（即如何拆分微服務，哪些服務應該拆到一起）、服務註冊、服務發現、微服務間的通訊。每個微服務都持有獨立的資料庫，無法做到資料強一致性，只能做到最終結果一致性。做微服務也會增加團隊的溝通成本。
微服務通訊方式
微服務可以使用兩種基本訊息傳遞模式 -- 同步與非同步訊息傳遞，來與其他微服務通訊。
-
同步通訊。 在此模式下，一個服務使用 HTTP 或 RPC（Remote Procedure Call，翻譯過來為“遠端過程呼叫”） 框架等協議呼叫另一個服務公開的 API。 此選項之所以稱作同步訊息傳遞模式，是因為呼叫方需要等待接收方返回的響應。比較通用的 RPC 框架有：gRPC（Google）、Thrift（Apache）
-
非同步訊息傳遞。 在此模式下，服務可以在不等待回應的情況下傳送訊息，然後一個或多個服務以非同步方式處理該訊息。比較流行的訊息佇列有：RabbitMQ、ZeroMQ、Kafka、ActiveMQ 至於具體怎麼通訊，後面會有詳細的分享。本文只是先介紹微服務如何通訊。
我們應該使用微服務嗎？
微服務已經成為一種熱門的架構模式了，開啟各大技術類網站幾乎都少不了微服務的身影。但微服務真的適合我們當下的使用者規模與公司級別嗎？這個問題，其實也沒有比較統一的答案。在我看來，其實大部分小公司是用不到微服務的，因為其不足遠大於其優勢，單體應用做好優化、資料庫讀寫分離、叢集、負載均衡，就能應對日常的流量。當你以上的優化都做了，還是撐不住壓力的話，就可以考慮微服務了。當然，服務架構選型還是看不同情況和公司意志的，如果有必要做跨語言等其他需求，那就做微服務的。
後記
最後，拋開業務上的原因，我們作為技術人也需要學習微服務相關的技術，不能侷限於用不上就不學習。在當下大環境下，儲備多一點知識，提高自身競爭力總是沒有壞處的。 個人的知識儲備總是有限的，如有錯誤的地方，還請大佬斧正。點選閱讀原文，連結到我的知乎，我會在知乎上對文章錯誤的地方進行修改。
本篇文章首發於公眾號「zone7」，關注公眾號獲取最新推文。