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