微服務架構設計綱要

微服務

軟件架構是一個包含各類組織的系統組織，這些組件包括 Web服務器, 應用服務器, 數據庫,存儲, 通信層), 它們彼此或和環境存在關係。系統架構的目標是解決利益相關者的關注點。

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

（設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。)

Monolithic架構

Monolithic比較適合小項目，優勢是：

開發簡單直接，集中式管理, 基本不會重複開發

功能都在本地，沒有分佈式的管理開銷和調用開銷。它的缺點也很是明顯，特別對於互聯網公司來講（不一一列舉了）：

開發效率低：全部的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷

代碼維護難：代碼功能耦合在一塊兒，新人不知道何從下手

部署不靈活：構建時間長，任何小修改必須從新構建整個項目，這個過程每每很長

穩定性不高：一個微不足道的小問題，能夠致使整個應用掛掉

擴展性不夠：沒法知足高併發狀況下的業務需求

微服務架構

微服務是指開發一個單個小型的但有業務功能的服務，每一個服務都有本身的處理和輕量通信機制，能夠部署在單個或多個服務器上。微服務也指一種種鬆耦合的、有必定的有界上下文的面向服務架構。也就是說，若是每一個服務都要同時修改，那麼它們就不是微服務，由於它們緊耦合在一塊兒；若是你須要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

相對於單體架構和SOA，它的主要特色是組件化、鬆耦合、自治、去中心化，體如今如下幾個方面：

• 一組小的服務

服務粒度要小，而每一個服務是針對一個單一職責的業務能力的封裝，專一作好一件事情。

• 獨立部署運行和擴展

每一個服務可以獨立被部署並運行在一個進程內。這種運行和部署方式可以賦予系統靈活的代碼組織方式和發佈節奏，使得快速交付和應對變化成爲可能。

• 獨立開發和演化

技術選型靈活，不受遺留系統技術約束。合適的業務問題選擇合適的技術能夠獨立演化。服務與服務之間採起與語言無關的API進行集成。相對單體架構，微服務架構是更面向業務創新的一種架構模式。

• 獨立團隊和自治

團隊對服務的整個生命週期負責，工做在獨立的上下文中，本身決策本身治理，而不須要統一的指揮中心。團隊和團隊之間經過鬆散的社區部落進行銜接。

咱們能夠看到整個微服務的思想就如咱們如今面對信息爆炸、知識爆炸是同樣的：經過解耦咱們所作的事情，分而治之以減小沒必要要的損耗，使得整個複雜的系統和組織可以快速的應對變化。

咱們爲何採用微服務呢？

"讓咱們的系統儘量快地響應變化" - Rebecca Parson

讓咱們的系統儘量快地去響應變化。其實幾十年來咱們一直在嘗試解決這個問題。若是必定要在前面加個限制的話，那就是低成本的快速響應變化。上世紀90年代Kent Beck提出要擁抱變化，在同期出現了諸多輕量級開發方法（諸如 XP、Scrum）；2001年敏捷宣言誕生，以後又出現了精益、看板等新的管理方式。若是說，這些是爲了儘快的響應變化，在軟件開發流程和實踐方面提出的解決方案，那麼微服務架構就是在軟件技術和架構層面提出的應對之道。

Autonomous
A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; it is fault tolerant and highly available

Responsive
A Microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented
Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
Microservices provide API’s for access by developers and administrators

Composable
Applications are composed from multiple Microservices

Automated
The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

服務之間如何通訊

通常同步調用比較簡單，一致性強，可是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個頗有意 思的話題。通常REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能調用，因此相對使用的廣一些。RPC也有本身的優勢，傳輸協議更高效，安全更可控，特別在一個公司內部，若是有統一個 的開發規範和統一的服務框架時，他的開發效率優點更明顯些。就看各自的技術積累實際條件，本身的選擇了。而異步消息的方式在分佈式系統中有特別普遍的應用，他既能減低調用服務之間的耦合，又能成爲調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢。不過須要付出的代價是一致性的減弱，須要接受數據最終一致性；還有就是後臺服務通常要 實現冪等性，由於消息發送出於性能的考慮通常會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分佈式管理也是一個很大的挑戰。

微服務優勢

• 每一個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
• 微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
• 微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段或部署階段都是獨立的。
• 微服務能使用不一樣的語言開發。
• 微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如Jenkins, bamboo 。
• 一個團隊的新成員可以更快投入生產。
• 微服務易於被一個開發人員理解，修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。
• 微服務容許你利用融合最新技術。
• 微服務只是業務邏輯的代碼，不會和HTML,CSS 或其餘界面組件混合。
• 微服務可以即時被要求擴展。
• 微服務能部署中低端配置的服務器上。
• 易於和第三方集成。
• 每一個微服務都有本身的存儲能力，能夠有本身的數據庫。也能夠有統一數據庫。

微服務架構的缺點

• 微服務架構可能帶來過多的操做。
• 須要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能雙倍的努力。
• 分佈式系統可能複雜難以管理。
• 由於分佈部署跟蹤問題難。
• 當服務數量增長，管理複雜性增長。

須要考慮的問題

• 單個微服務代碼量小，易修改和維護。可是，系統複雜度的總量是不變的，每一個服務代碼少了，但服務的個數確定就多了。就跟拼圖遊戲同樣，切的越碎，越難拼出整幅圖。一個系統被拆分紅零碎的微服務，最後要集成爲一個完整的系統，其複雜度確定比大塊的功能集成要高不少。
• 單個微服務數據獨立，可獨立部署和運行。雖然微服務自己是能夠獨立部署和運行的，但仍然避免不了業務上的你來我往，這就涉及到要對外通訊，當微服務的數量達到必定量級的時候，如何提供一個高效的集羣通訊機制成爲一個問題。
• 單個微服務擁有本身的進程，進程自己就能夠動態的啓停，爲無縫升級的打好了基礎，但誰來啓動和中止進程，什麼時機，選擇在哪臺設備上作這件事情纔是無縫升級的關鍵。這個能力並非微服務自己提供的，而是須要背後強大的版本管理和部署能力。
• 多個相同的微服務能夠作負載均衡，提升性能和可靠性。正是由於相同微服務能夠有多個不一樣實例，讓服務按需動態伸縮成爲可能，在高峯期能夠啓動更多的相同的微服務實例爲更多用戶服務，以此提升響應速度。同時這種機制也提供了高可靠性，在某個微服務故障後，其餘相同的微服務能夠接替其工做，對外表現爲某個設備故障後業務不中斷。一樣的道理，微服務自己是不會去關心繫統負載的，那麼何時應該啓動更多的微服務，多個微服務的流量應該如何調度和分發，這背後也有一套複雜的負載監控和均衡的系統在起做用。
• 微服務能夠獨立部署和對外提供服務，微服務的業務上線和下線是動態的，當一個新的微服務上線時，用戶是如何訪問到這種新的服務？這就須要有一個統一的入口，新的服務能夠動態的註冊到這個入口上，用戶每次訪問時能夠從這個入口拿到系統全部服務的訪問地址。這個統一的系統入口並非微服務自己的一部分，因此這種能力須要系統單獨提供。
• 還有一些企業級關注的系統問題，好比，安全策略如何集中管理？系統故障如何快速審計和跟蹤到具體服務？整個系統狀態如何監控？服務之間的依賴關係如何管理？等等這些問題都不是單個微服務考慮的範疇，而須要有一個系統性的考慮和設計，讓每一個微服務都可以按照系統性的要求和約束提供對應的安全性，可靠性，可維護性的能力。

API爲何很重要

• 服務價值的精華體現
• 可靠、可用、可讀
• 只有一次機會

實現一個API網關做爲全部客戶端的惟一入口。API網關有兩種方式來處理請求。有些請求被簡單地代理/路由到合適的服務上，其餘的請求被轉給到一組服務。

相比於提供普適的API，API網關根據不一樣的客戶端開放不一樣的API。好比，Netflix API網關運行着客戶端特定的適配器代碼，會向客戶端提供最適合其需求的API。

API網關也能夠實現安全性，好比驗證客戶端是否被受權進行某請求。

設計要素

• Version
• RequstID
• Auth&Signature
• RateLimit
• Docs
• ErrorCode&Message

微服務治理

• 按需伸縮

–部署與監控運維成本

• 獨立部署

–機器數量與部署成本

• 業務獨立

–服務依賴、治理，版本管理、事務處理

• 技術多樣性

–環境部署成本、約定成本

• 運行狀態治理

–監控、限流、SLA、LB、日誌分析

• 服務註冊與發現
• 部署

–快速、複製、擴容
–單機開發

• 調用

–安全、容錯、服務降級、調用延時

服務容錯

當企業微服務化之後，服務之間會有錯綜複雜的依賴關係，例如，一個前端請求通常會依賴於多個後端服務，技術上稱爲1 -> N扇出. 在實際生產環境中，服務每每不是百分百可靠，服務可能會出錯或者產生延遲，若是一個應用不能對其依賴的故障進行容錯和隔離，那麼該應用自己就處在被拖垮的風險中。在一個高流量的網站中，某個單一後端一旦發生延遲，可能在數秒內致使全部應用資源(線程，隊列等)被耗盡，形成所謂的雪崩效應(Cascading Failure)，嚴重時可致整個網站癱瘓。

服務依賴

服務框架

1. 服務註冊、發現、負載均衡和健康檢查，假定採用進程內LB方案，那麼服務自注冊通常統一作在服務器端框架中，健康檢查邏輯由具體業務服務定製，框架層提供調用健康檢查邏輯的機制，服務發現和負載均衡則集成在服務客戶端框架中。
2. 監控日誌，框架一方面要記錄重要的框架層日誌、metrics和調用鏈數據，還要將日誌、metrics等接口暴露出來，讓業務層能根據須要記錄業務日誌數據。在運行環境中，全部日誌數據通常集中落地到企業後臺日誌系統，作進一步分析和處理。
3. REST/RPC和序列化，框架層要支持將業務邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是當前主流API暴露方式，在性能要求高的場合則可採用Binary/RPC方式。針對當前多樣化的設備類型(瀏覽器、普通PC、無線設備等)，框架層要支持可定製的序列化機制，例如，對瀏覽器，框架支持輸出Ajax友好的JSON消息格式，而對無線設備上的Native App，框架支持輸出性能高的Binary消息格式。
4. 配置，除了支持普通配置文件方式的配置，框架層還可集成動態運行時配置，可以在運行時針對不一樣環境動態調整服務的參數和配置。
5. 限流和容錯，框架集成限流容錯組件，可以在運行時自動限流和容錯，保護服務，若是進一步和動態配置相結合，還能夠實現動態限流和熔斷。
6. 管理接口，框架集成管理接口，一方面能夠在線查看框架和服務內部狀態，同時還能夠動態調整內部狀態，對調試、監控和管理能提供快速反饋。Spring Boot微框架的Actuator模塊就是一個強大的管理接口。
7. 統一錯誤處理，對於框架層和服務的內部異常，若是框架層可以統一處理並記錄日誌，對服務監控和快速問題定位有很大幫助。
8. 安全，安全和訪問控制邏輯能夠在框架層統一進行封裝，可作成插件形式，具體業務服務根據須要加載相關安全插件。
9. 文檔自動生成，文檔的書寫和同步一直是一個痛點，框架層若是能支持文檔的自動生成和同步，會給使用API的開發和測試人員帶來極大便利。Swagger是一種流行Restful API的文檔方案。
10. 想要了解更多微服務架構知識點的，能夠關注我一下，我後續也會整理更多這一塊的知識點分享出來，另外順便在這裏給你們推薦一個Java後端的交流社區：586446657，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。相信對於已經工做和遇到技術瓶頸的碼友，在這裏必定有你須要的內容。

微服務系統底座

一個完整的微服務系統，它的底座最少要包含如下功能：

• 日誌和審計，主要是日誌的彙總，分類和查詢
• 監控和告警，主要是監控每一個服務的狀態，必要時產生告警
• 消息總線，輕量級的MQ或HTTP
• 註冊發現
• 負載均衡
• 部署和升級
• 事件調度機制
• 資源管理，如：底層的虛擬機，物理機和網絡管理

如下功能不是最小集的一部分，但也屬於底座功能：

• 認證和鑑權
• 微服務統一代碼框架，支持多種編程語言
• 統一服務構建和打包
• 統一服務測試
• 微服務CI/CD流水線
• 服務依賴關係管理
• 統一問題跟蹤調試框架，俗稱調用鏈
• 灰度發佈
• 藍綠部署

容器（Docker）與微服務

• 容器夠小

–解決微服務對機器數量的訴求

• 容器獨立

–解決多語言問題

• 開發環境與生產環境相同

–單機開發、提高效率

• 容器效率高

–省錢

• 代碼/image一體化

–可複用管理系統

• 容器的橫向與縱向擴容

–可複製
–可動態調節CPU與內存

容器(Docker)與微服務

• Image管理
• 系統安全管理
• 受權管理
• 系統成熟度
• 社區成熟度

開發方式影響

隨着持續交付概念推廣以及Docker容器普及，微服務將這兩種理念和技術結合起來，造成新的微服務+API + 平臺的開發模式，提出了容器化微服務的持續交付概念。
下圖傳統Monolithic的DevOps開發隊伍方式：

這種總體型架構要求產品隊伍橫跨產品管理 Dev開發 QA DBA 以及系統運營管理，而微服務架構引入之後，以下圖：

微服務促進了DevOps方式的重組，將一個大臃腫的總體產品開發隊伍切分爲根據不一樣微服務的劃分的產品隊伍，以及一個大的總體的平臺隊伍負責運營管理，二者之間經過API交互，作到了鬆耦合隔絕。

• 首先須要考慮構建DevOps能力，這是保證微服務架構在持續交付和應對複雜運維問題的動力之源；
• 其次保持服務持續演進，使之可以快速、低成本地被拆分和合並，以快速響應業務的變化；
• 同時要保持團隊和架構對齊。微服務貌似是技術層面的變革，但它對團隊結構和組織文化有很強的要求和影響。識別和構建匹配架構的團隊是解決問題的另外一大支柱。
• 最後，打造持續改進的自組織文化是實施微服務的關鍵基石。只有持續改進，持續學習和反饋，持續打造這樣一個文化氛圍和團隊，微服務架構才能持續發展下去，保持新鮮的生命力，從而實現咱們的初衷。

微服務的實施是有必定的先決條件：基礎的運維能力（如監控、快速配置、快速部署）需提早構建，不然就會陷入如咱們般被動的局面。推薦採用基礎設施及代碼的實踐，經過代碼來描述計算和網絡基礎設施的方法，使得圖案度i能夠快速安全的搭建和處理由新的配置代替的服務器，服務器之間能夠擁有更高的一致性，下降了在「個人環境工做，而你的環境不工做」的可能，也是爲後續的發佈策略和運維提供更好的支撐。

因爲Docker引入，不一樣的微服務可使用不一樣的技術架構，好比Node.js Java Ruby Python等等，這些單個的服務均可以獨立完成交付生命週期，以下：

微服務案例

Netflix的微服務架構以下，着重全球分發 高可擴展性和可用性：

Twitter的微服務架構，注重高效的可擴展的數據中心：

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

但願對您系統架構，軟件項目開發,運維管理，系統架構與研發管理體系, 信息安全, 企業信息化等有幫助。

文章轉載自博客園：PetterLiu

原文連接：www.cnblogs.com/wintersun/p…