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