軟件架構，總是在不斷的演進中...
成都創(chuàng)新互聯(lián)公司網(wǎng)站建設提供從項目策劃、軟件開發(fā)，軟件安全維護、網(wǎng)站優(yōu)化(SEO)、網(wǎng)站分析、效果評估等整套的建站服務，主營業(yè)務為成都做網(wǎng)站、成都網(wǎng)站建設，重慶APP開發(fā)以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。成都創(chuàng)新互聯(lián)公司深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
把時間退回到二十年之前，當時企業(yè)級領域研發(fā)主要推崇的還是C/S模式，PB、Delphi這樣的開發(fā)軟件是企業(yè)應用開發(fā)的主流。隨著時間的推移，基于瀏覽器的B/S架構開始漸漸流行了起來。初期，Web開發(fā)ASP還占據(jù)了不少優(yōu)勢，但JSP的預編譯模式讓性能有了很大提升，隨后基于JAVA語言的J2EE架構變得越來越流行。
早期軟件架構基本都是單體架構，系統(tǒng)之間往往不需要進行交互，這也導致數(shù)據(jù)孤島和ETL工具的發(fā)展。隨著企業(yè)應用越來越多，相互的關系也越來密切，應用之間也迫切需要進行實時交互訪問，隨后基于XML的異構系統(tǒng)集成和數(shù)據(jù)交互技術開始被很多公司采用，SOA的概念被提了出來，web service逐漸流行。
互聯(lián)網(wǎng)時代，很多公司為了適應更加靈活的業(yè)務需求，基于HTTP協(xié)議和Restful的架構風格及簡潔和結構清晰的JSON語言成為企業(yè)開發(fā)的最佳實踐，在SOA架構中，企業(yè)服務總線技術ESB所暴露的集中式架構的劣勢讓開發(fā)者明白基于注冊和發(fā)現(xiàn)的分布式架構才是解決問題的關鍵辦法。由此，微服務架構開始盛行。
在《微服務設計》中如何界定一個微服務，就是使用松耦合&高內(nèi)聚原則，把因相同因素變化的事情聚集在一起，把因不同因素變化的事情區(qū)隔開來。
微服務，其實是一種架構風格...
服務不同最適合的技術方案不同，微服務可以幫助我們輕松采用不同的技術，并且理解這些新技術的好處。嘗試新技術通常伴隨著風險，但對于微服務系統(tǒng)而言，總會存在一些地方讓你可以選擇一個風險最小的服務采用新技術，并降低風險。
微服務架構將系統(tǒng)分解為獨立運行單元，給系統(tǒng)帶來更好的隔離性，獨立的微服務在發(fā)生異常時更容易定位和隔離問題，隔離性也是服務擴展性的基礎。
龐大的單體服務只能作為一個整體進行擴展，即使系統(tǒng)中只有一小部分模塊存在性能問題，也需要對整個系統(tǒng)進行擴展。而微服務架構可以根據(jù)性能需要對不同的模塊進行水平擴展，微服務的彈性也可以很好地處理服務不可用和功能降級問題。
在微服務架構中，各個服務的部署是獨立的，這樣就可以更快地對特定部分的代碼進行部署。服務出現(xiàn)問題也更容易快速回滾，同時敏捷的交付和部署帶來了更好的業(yè)務需求響應體驗。
在微服務架構中，系統(tǒng)會開放很多接口供外部使用，當情況發(fā)生改變時，可以使用不同的方式構建應用。而整體化的應用程序只能提供一個非常粗粒度的接口供外部使用。把單體應用分解成多個微服務，可以達到可復用、可組合的目的。
下圖是一個典型的微服務架構，僅供參考。
微服務網(wǎng)關是微服務架構中的一個關鍵的角色，用來保護、增強和控制對于微服務的訪問，微服務網(wǎng)關是一個處于應用程序或服務之前的系統(tǒng)，用來管理授權、訪問控制和流量限制等，這樣微服務就會被微服務網(wǎng)關保護起來，對所有的調(diào)用者透明。因此，隱藏在微服務網(wǎng)關后面的業(yè)務系統(tǒng)就可以更加專注于業(yè)務本身。
常見的微服務網(wǎng)關根據(jù)使用特性大致被分成流量網(wǎng)關和業(yè)務網(wǎng)關。兩種網(wǎng)關分別有不同關注點，下圖總結了兩種網(wǎng)關類型特性：
微服務網(wǎng)關作為連接服務的消費方和服務提供方的中間件系統(tǒng)，將各自的業(yè)務系統(tǒng)的演進和發(fā)展做了天然的隔離，使業(yè)務系統(tǒng)更加專注于業(yè)務服務本身，同時微服務網(wǎng)關還可以為服務提供和沉淀更多附加功能，微服務網(wǎng)關主要作用如下：
SIA-GATEWAY是基于SpringCloud微服務生態(tài)體系下開發(fā)的一個分布式微服務網(wǎng)關系統(tǒng)。具備簡單易用、可視化、高可擴展、高可用性等特征，提供云原生、完整及成熟的接入服務解決方案。
下圖是SIA-GATEWAY的整體架構圖，架構由CORE和 Admin Cluster組成，其中：
網(wǎng)關的整體部署架構如下圖所示：
微服務網(wǎng)關系統(tǒng)是一個處于應用程序或服務（提供REST API接口服務）之前的中間件系統(tǒng)， SIA-GateWay在建設初期做技術選型時就充分考慮到所使用的技術方案應該兼容后端代理業(yè)務系統(tǒng)所使用的技術棧和技術體系，因此我們使用了Netflix的ZUUL作為網(wǎng)關系統(tǒng)技術棧，單純的脫離使用場景談某一種網(wǎng)關功能如何強大的做法，后續(xù)都會給業(yè)務方的使用帶來更多的麻煩。
更明確的說如果目前大部分業(yè)務系統(tǒng)采用的技術棧是JAVA系統(tǒng)， 那么不建議使用Nginx、Kong或者OpenResty等網(wǎng)關系統(tǒng)，這里主要是出于軟件工程性方面考慮。
舉個例子，業(yè)務方需要將一個公共組件以Plugin 機制集成到微服務網(wǎng)關， 如果使用Lua腳本文件或者其他腳本語言，那么引入一種新的語言技術棧所帶來的復雜度會給業(yè)務系統(tǒng)帶來更多的不確定性，系統(tǒng)后期維護成本和運維的難度都會呈指數(shù)級的提升。
微服務網(wǎng)關的一個很重要的作用就是可以將微服務的API聚合后，提供一個統(tǒng)一的EntryPoint作為業(yè)務使用方的一個統(tǒng)一入口，以及屏蔽和隱藏業(yè)務內(nèi)部邏輯。下面是SIA-GateWay提供的公共組件類型及分類。
目前SIA-GateWay通過組件管理的機制實現(xiàn)了5個大類8個子類的公共服務組件供業(yè)務方使用，其中提供的路由組件綁定機制可以讓業(yè)務方靈活地決定是否要在運行時執(zhí)行相關組件邏輯。
微服務架構的一個重要特性就是去中心化的架構設計思路，SIA-GateWay在軟件設計層面上增加了一個“網(wǎng)關組”的抽象概念，一個網(wǎng)關組對應一個獨立的業(yè)務領域。網(wǎng)關組的概念也契合了微服務架構中的一些理念：業(yè)務系統(tǒng)依賴微服務網(wǎng)關提供明確清晰的服務邊界；業(yè)務系統(tǒng)通過微服務網(wǎng)關對外暴露業(yè)務的標準服務接口。
從實現(xiàn)層面，SIA-GateWay充分利用并結合了容器自動化的部署技術，在解決最后一公里的問題上，將網(wǎng)關以云端容器資源的方式交付給不同業(yè)務方，通過共享網(wǎng)關SDK部署包的方式將網(wǎng)關的服務下沉到容器中實現(xiàn)和執(zhí)行，從而在時間和空間上做到了系統(tǒng)的彈性和靈活交付。同時中心化的管理能力又給使用網(wǎng)關的具有不同權限的用戶可以同時維護各自所屬網(wǎng)關組下的網(wǎng)關節(jié)點帶來了便利。
上圖展示的是SIA-GateWay去中心化的網(wǎng)關架構。當然除了微服務網(wǎng)關模式，目前下一代微服務架構ServiceMesh技術也是典型的去中心化架構，ServiceMesh是從SideCar邊車模式演進而來，是一種通過將服務治理能力下沉到業(yè)務節(jié)點的方式，通過控制面（control plane）和數(shù)據(jù)面（data plane）的處理解耦分離實現(xiàn)服務通信更加快速、便捷、智能。
然而目前來看，從技術上及各大公司的實踐中，ServiceMesh在落地方面還存在諸多復雜性及不可控性，這種模式會給運維帶來極大的成本，如果貿(mào)然使用會給本就復雜的分布式系統(tǒng)帶來更多的復雜和難度。而GateWay網(wǎng)關的模式在組織粒度上可以調(diào)整，在實現(xiàn)方式上更加簡單可控，是目前的微服務架構中比較適合采用的模式。
作為一個微服務網(wǎng)關系統(tǒng)，因為所有流量都會經(jīng)過網(wǎng)關，網(wǎng)關必須成為一個高可用的中間件服務，網(wǎng)關系統(tǒng)的穩(wěn)定性及可用性直接決定了所用下游服務的穩(wěn)定性。因此SIA-GateWay在架構設計上主要做了如下幾點：
1）集群化
在生產(chǎn)環(huán)境中，所用網(wǎng)關節(jié)點至少保證有2個節(jié)點組成集群同時提供服務，目前SIA-GateWay在公司內(nèi)部主要使用容器化部署，避免單點故障。
2）健康檢查
在容器環(huán)境下，SIA-GateWay會暴露一個HTTP健康檢查接口，通過Kubernetes的健康檢查機制，定期檢查HTTP訪問是否可用，如果不可用，利用Kubernetes的服務編排能力可以做容器的切換；在Zstack環(huán)境下， 通過后臺啟動一個Crontab作為守護進程檢查進程的狀態(tài)，保證網(wǎng)關的穩(wěn)定可用和進程重啟機制。
3）備份機制
SIA-GateWay提供了一種備份網(wǎng)關機制，在Zstack上會啟動一個備份網(wǎng)關API-GATEWAY-CORE，所有在容器環(huán)境（Kubernetes）中啟動的網(wǎng)關節(jié)點，都會將自己的路由信息同步到備份網(wǎng)關中。
另外，利用Nginx的高可用性和健康檢查機制，當Kubernetes集群出現(xiàn)問題，所有容器流量無法響應時，會將Nginx上的流量自動切換到API-GATEWAY-CORE備份節(jié)點。API-GATEWAY-CORE在工作時也會觸發(fā)預警，提示目前有不可用的K8s網(wǎng)關節(jié)點。
Unix編程哲學里，一個重要的概念是：“提到機制而不是策略”，通俗的講“機制”就是接口，“策略”就是具體的實現(xiàn)。SIA-GateWay提供的組件集成能力正是基于這樣的理念。
SIA-GateWay將架構的可擴展性作為重要的對外輸出能力，第三方插件機制主要支持JAVA語言的Filter組件動態(tài)加載機制。Filter機制是JAVA工程師最為熟悉的標準組件，所以對于業(yè)務方集成自己的業(yè)務邏輯提供了極大的便利，第三方業(yè)務組件加載到網(wǎng)關平臺大體有如下幾個步驟：
下圖是SIA-GateWay組件加載機制的執(zhí)行邏輯圖：
俗話說流水的架構，鐵打的監(jiān)控，任何架構都需要軟件監(jiān)控。微服務應用本身RPC的交互方式帶來了對監(jiān)控系統(tǒng)了解系統(tǒng)運行狀態(tài)的難題。SIA-GateWay對微服務監(jiān)控主要做了如下方面增強：
1）全局的集群狀態(tài)查看和容器狀態(tài)DashBoard統(tǒng)計。
2）實時的路由拓撲和網(wǎng)關拓撲調(diào)用關系及狀態(tài)展示。實時的路由拓撲圖如下：
3）網(wǎng)關集群拓撲管理界面，包含實時日志、實時Hystix監(jiān)控、JVM配置等。
4）可視化的組件管理界面。
5）日志回溯，利用EKK架構實現(xiàn)日志歸集到日志查看功能。
6）熔斷管理的分類及錯誤Stacktrace查看。
7）URL細粒度的監(jiān)控統(tǒng)計功能（默認不打開，需要路由綁定監(jiān)控組件）,包括URL的延遲統(tǒng)計，調(diào)用計數(shù)等指標。
軟件工程沒有銀彈，軟件系統(tǒng)的不確定性和復雜性貫穿軟件工程的整個生命周期，微服務架構本質(zhì)上是通過分層和解耦來降低系統(tǒng)的復雜性，這里組織的溝通方式、企業(yè)文化、團隊技術學習能力都會對微服務架構的落地產(chǎn)生重要的影響。
對業(yè)務系統(tǒng)的核心能力洞察和業(yè)務邊界的識別是系統(tǒng)微服務架構落地的重要環(huán)節(jié)；微服務基礎設施的技術選型應該考慮到業(yè)務系統(tǒng)所使用的技術體系，選擇成熟的生態(tài)體系和合適的技術方案有利于微服務架構的推廣和持續(xù)的技術演進；SIA-GATEWAY作為微服務基礎設施充分考慮到了與業(yè)務系統(tǒng)的兼容性和相關技術生態(tài)的成熟度。
最后在微服務架構下，隨著微服務規(guī)模的擴大，必然帶來分布式事務一致性、網(wǎng)絡響應、容錯等等問題， 所以微服務治理是微服務架構的難點，保障微服務架構的高可用和高可擴展性需要在基礎設施層面增加更多的技術投入和技術保障， 這樣才能讓業(yè)務更好的專注于業(yè)務實現(xiàn)、敏捷的開發(fā)、持續(xù)快速的服務交付。
作者： 王佩華
重慶分公司
重慶分公司
