什么是微服務？
在了解微服務架構前，我們需要先了解什么是微服務
在傳統單體架構（如上圖左側）中，我們一個項目的所有模塊是聚合在一個程序中。我們所有模塊數據都存放到一個數據庫中。因為這種架構很簡單的原因，所以開發效率很快，部署方便，在項目初期階段比較常用。但隨著項目復雜度增加，開發規模上升缺點也有很多比如：模塊之間代碼容易引起沖突，因為太容易修改到同一個文件了。還有就是一個小改動也需要整體上線，線上穩定性很難得到保證。
隨著軟件架構的不斷演進，微服務架構逐漸流行起來。在微服務架構（如上圖右側）中，模塊是獨立運行的進程服務，每個模塊都有獨立的數據庫，當業務流量增大時可以通過增加部署實例的方式來應對。
「 微服務 」的理念提倡每個服務都是單一職責，且每一個服務都能實現自治，因此可以帶來一些明顯好處：
部署簡單：每個微服務都可以獨立去部署，方便快捷。
邏輯清晰：將一個獨立功能邏輯封裝在單一微服務里面，實現整體項目的邏輯清晰。
可擴展：因為可以隨時增加和減少微服務，可以很方便的擴展功能。
可靠性高：某一個功能的異常可以隔離在單一微服務里面，可以提高整體可靠性。
微服務架構實現形式
實現形式大致有三種：
基于云原生的微服務
當前概念最火的微服務實現方式，這種方式需要依賴k8s集群來管理服務的容器。
如上圖，每個微服務其實就一個Service，Pod是每個服務的部署實例。服務的對外訪問提供需要依賴Ingress來實現。
優點很多： 需要考慮服務注冊發現問題（內部已集成）、支持容器的彈性伸縮等
存在問題： 非云原生的應用無法使用、架構復雜導致運維成本很高、
基于微服務框架的微服務
JAVA系的spring-cloud、Go系的go-micro都是微服務框架的代表。 上圖以go-micro為例進行說明：
Register確保每個Server的啟動和消亡最終寫入到Consul。Client是請求服務的接口，請求服務時會先使用Selector選擇一個服務器，然后再經過transport和codec的最終抵達目標Server.
優點：內部集成了服務注冊發現、服務間調用都是代碼形式實現更便捷、插件豐富
缺點：與開發語言強綁定、功能復用性不強（A服務的功能，即使做成公共庫其他服務也需要調用才行）
基于網關的微服務
基于網關的微服務架構，我們以GateKeeper進行說明。
1、用戶通過接入層 (一般選用 Nginx、Haproxy、LVS) 連接到 GateKeeper 實例中。
2、每個 GateKeeper 實例，針對每個子服務模塊，單獨進行服務探測。
3、在線服務管理時，配置數據先保存到 GateKeeper 配置 DB 中，然后再通過調用配置更新接口（ /reload ），更新所有實例機器配置。
基于網關的微服務架構優勢：
1、網關提供服務的注冊發現機制和負載均衡
2、外部訪問可以直接使用網關接入，內部服務互調也可以經由網關接入
3、網關可提供額外的其他功能拓展支持（如：登陸、權限驗證）只實現一次多出調用。
4、接入的服務不受語言限制
5、非云原生應用、云原生應用皆可使用。
為什么考慮開發 GateKeeper?
我們公司項目在發展初期時，我們的服務比較少。而且大多是內部服務，對外服務只有一個后端（php）。18年下半年 隨著業務發展，增加了N多個服務模塊。考慮到之前的單體架構已經無法滿足當前需求了，所以開始考慮微服務化劃分，在劃分好業務邊界后，我們整理出共 10+個服務，5個服務需要對外服務。
這5個對外服務在部署完畢后首要解決的問題是需要接入用戶權限系統（UPM），因為之前功能是下掛在PHP系統中的，當時我們考慮了三種方式：
1、是多個服務單獨接入UPM、SSO系統。這樣成本很高而且相同代碼需要多出維護。
2、是仍然使用之前的 PHP項目當做外層項目，通過轉發請求做統一權限和登陸操作。這是當時成本最低的方式。
3、獨立做一個權限和登陸的API gateway，讓它作為統一接入服務。以后再加項目時加一個配置即可。
從長遠發展以及通用性來說我們最終選擇了，獨立做一個 API gateway。
為什么不選擇主流API gateway，而是采用自研？
首先，當前GO這個技術棧 沒有成熟的API gateway。
另外其他主流的API gateway，大多都有依賴軟件較多的問題，比如要實現動態服務注冊就需要 Consul這類的分布式數據庫。
而我們的業務有時候需要本地化部署，這就需要：依賴少、快速簡易部署、支持多種權限配置等。
綜合以上因素，我們就考慮使用GO自研API網關了。
我們下一步的精力主要會放在三個方面：
1、持續不斷推進項目穩定性建設和問題修復。
2、增加示例代碼，讓使用者更加容易、便捷。
3、增加新特性：熔斷機制、基于云原生的部署等
end：如果你覺得本文對你有幫助的話，記得關注點贊轉發，你的支持就是我更新動力。
