微服務架構

  微服務一詞來源于Martin Fowle寫的一篇文章，開發者可以點擊 這里，閱讀該文章詳情，閱讀中文翻譯請點擊 這里。

  簡單來說，微服務是系統架構上的一種設計風格，它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運 行，服務之間通過基于HTTP的RESTful風格的API進行通信協作。注意被拆分的每一個小型服務都是圍繞著系統中某一項或者一些耦合度較高的業務功能進行構建，并且每個服務都維護著自身的數據存儲、業務開發、自動化測試案例以及獨立部署機制。由于存在輕量級的通信協議作基礎，因此這些微服務可以使用不同的語言來不編寫。     

與單體系統的區別

  在以往傳統的企業系統架構中，我們針對一個復雜的業務需求通常使用對象或業務類型來構建一個單體項目。在項目中通常將需求分為三個主要部分：數據庫、服務端處理、前端展現。在業務發展初期，由于所有的業務邏輯在一個應用中，開發、測試、部署都還比較容易且方便。但是隨著企業的發展，系統為了應對不同的業務需求會不斷為該單體項目增加不同的業務模塊；同時隨著移動設備的進步，前端展現模塊已經不僅僅局限于Web的形式，這對于系統后端向前端的支持需要更多的接口模塊。不斷擴大的需求使得單體應用變得越來越臃腫，因此單體應用的缺點也越來越明顯。由于單體系統部署在一個進程內，因此當我們修改了一個很小的功能，然后部署上線很可能會影響其他功能的運行。且單體應用中的各個模塊的使用場景、并發量、消耗的資源類型等都是不同的，對于資源的利用又是互相影響，這樣無疑給我們對于各個業務模塊的系統容量的評估帶來巨大的影響，這么看來盡管單體系統在初期可以很方便的進行開發和使用，但是隨著系統的發展，毫無疑問其維護成本會變得越來越大，且非常難以控制。

  為了解決單體系統變得臃腫后難以維護的問題，微服務架構孕育而生。我們可以將系統中不同的功能模塊拆分成多個不同的服務，這些服務都能夠獨立部署和擴展。由于每個服務都運行在自己的進程內，在部署上有穩固的邊界，這樣每個服務的更新都不會影響到其他服務的運行。同時由于各個服務均是獨立部署的，因此可以更為準確的為每個服務進行性能容量評估，與此同時通過配合服務間的協作流程也可以更容易的發現系統的瓶頸位置，并給出較為準確的系統級性能容量評估。     

微服務帶來的挑戰

  在實施微服務之前，有必要知道因為微服務的拆分而引發了諸多原本在單體應用中沒有的問題和挑戰：

（1）運維的新高度。 在微服務架構中，由于系統的拆分，使得運維人員需要維護的進程數量大大增加，這就要求運維人員具備一定的開發能力來編排運維過程并讓它們能自動運行起來。

（2）接口的一致性。 雖然我們拆分了服務，但是業務邏輯上的依賴并不會消除，只是從單體應用中的代碼依賴變為了微服務間的通信依賴。這就使得開發者對原有接口進行了一絲修改，那么與之對應的交互方也需要協調這樣的改變來進行發布，以保證接口的正確調用。也就是說此時需要更完善的接口和版本管理，或者是嚴格遵循開閉原則。

（3）分布式的復雜性。 由于拆分后的各個微服務都是獨立部署并運行在各自的進程內，它們只能通過通信來進行協作，所以分布式環境的問題都是微服務架構設計時需要考慮的重要因素，如網絡延遲、分布式事務、異步消息等。

  盡管微服務架構中存在很多缺點，但是你知道的凡是都有兩面性，關鍵在于如何取舍，當你覺得微服務架構中實現的敏捷開發、自動化部署等是你著重需要考慮的問題，那么此時選擇微服務架構是不錯的選擇。

微服務9大特性

  由于存在環境、資源、團隊等各種因素的影響，因此架構師在對一個大型系統架構的設計與實施過程中幾乎不會出現完全相同的架構設計。對于微服務架構而言更是如此，由于微服務架構只是一種建議，不是硬性規定，因此架構師通常會根據自身理解和實際情況來進行設計，并在發展的過程中不斷演進和完善。當然了，俗話說的好，不以規矩無以成方圓，因此非服務架構存在9大特性，通過這9大特性的學習，對于架構師設計架構有著指導性意義。

（1）服務組件化。 所謂的組件，是指一個可以獨立更換和升級的單元。在微服務架構中，需要我們對服務進行組件化分解。服務，是一種進程外的組件，它通過HTTP等通信協議進行協作，而不是像傳統組件那樣以嵌入的方式協調工作。每一個服務都獨立開發、測試、部署，可以有效的避免一個服務的修改引起整個系統的重新部署。

（2）按業務組織團隊。 當決定如何劃分微服務時，通常也意味著我們要開始對團隊進行重新規劃和組織。按照以往的方式，我們會從技術層面將團隊劃分為多個，如DBA團隊，運維團隊，后端團隊，前端團隊，設計師團隊等。但是如果我們此時還按照這種方式組織團隊來實施微服務架構開發，那么極易出現當一個服務需要修改時（可能是一個非常簡單的變動，如對某個對象新增一個字段等），那么這就要求從數據存儲開始考慮一直到設計和前端，盡管大家修改的內容很少，甚至部分節點是不需要修改的，但是這勢必會造成不必要的跨團隊溝通，而這在企業中盡量是需要避免的。

  在微服務架構的實施時，需要采用不同的團隊分割方法。由于每一個服務都是針對特定業務的寬棧或者是全棧實現，既要負責數據的持久化存儲，又要負責用戶的接口定義等各種跨專業領域職能。因此在面對大型項目的時候，對于微服務團隊的拆分筆者建議按照業務線的方式進行拆分，一方面可以有效的減少服務內部修改所產生的內耗；另一方面團隊的邊界變得更加清晰。

（3）做產品的態度。 在實施微服務架構的團隊中，每個小團隊都應該是以做產品的方式對其產品的整個生命周期負責，而不是以項目的模式，以完成開發與交互并將成果交給維護者為最終目標。

  一般來說，開發團隊通過了解服務在具體生產環境中的情況，可以增加他們對于具體業務的理解，所以需要開發者用做產品的態度來對待每一個微服務，持續關注服務的運作情況，并不斷分析以幫助用戶來改善業務功能。

（4）智能端點與啞管道。 在單體應用中，組件之間可以直接通過函數調用的方式來進行交互協作；而在微服務架構中，由于服務不在一個進程中，因此組件的通信模式發送了變化，如果僅僅是將原本在進程內的方法調用改成RPC方式的調用，這樣會導致微服務之間產生繁瑣的通信，使得系統表現更為糟糕，因此我們需要更粗粒度的通信協議。

  在微服務架構中，一般會使用如下兩種服務調用方式：（1）使用HTTP的RESTful風格的API或者輕量級的消息發送協議，實現消息傳遞與服務調用的觸發。（2）通過在輕量級的消息總線上傳遞消息，使用類似于RabbitMQ等一些提供可靠異步交換的中間件。

  除了上述兩種方式之外，在一些極度強調性能的情況下，有些團隊會使用二進制的消息發送協議，如protobuf。但是即便是這樣，這些系統依舊可能出現前面說的“智能端點與啞管道”的特點，這是為了在易讀性和高效性之間取得平衡。當然了，大多數的Web應用或者企業系統其實并不需要在這兩者之間做出選擇，因為能夠獲得易讀性已經是非常不錯了。

（5）去中心化治理。 當我們采用集中化的架構治理方案時，通常在技術平臺上都會制定統一的標準，但是每一種技術都有它合適的應用場景，并不是適合所有的場景，這樣在碰到其短板時，就需要花費大力氣去解決，而且極有可能在日后成為系統的瓶頸。

  在實施微服務架構時，通過采用輕量級的契約定義接口，使得我們對于服務本身的技術平臺不再那么敏感，這樣整個微服務架構系統中的各個組件就能針對其不同的業務特點選擇不同的技術平臺，使用最合適的技術，這樣就不會出現殺雞焉用牛刀的尷尬局面。

  我非常喜歡一句話：不是每個問題都是釘子，也不是每個解決方案都是錘子。

（6）去中心化管理數據。 我們在實施微服務架構時，都希望讓每一個服務來管理其自有的數據庫，這其實就是數據管理的去中心化。

  在去中心化過程中，我們除了將原數據庫中的存儲內容拆分到新的的同平臺的其他數據庫實例之中（如將原本存儲在MySQL中的表拆分后，存儲到多個不同的MySQL實例中），當然也可以將一些具有特殊結構或者業務特性的數據存儲到一些其他技術的數據庫實例中，如將日志信息存儲到MongoDB或者將用戶信息存儲到Redis中。

  雖然數據管理的去中心化可以讓數據管理變得更加細致化，之后通過采用更合適的技術可以讓數據存儲和性能達到最優解。但是由于數據存儲于不同的數據庫實例中，那么數據一致性也就成了微服務架構中亟待解決的問題，而分布式事務本身實現的難度就非常大，因此在微服務架構中我們更強調在各服務之間進行“無事務”的調用，而對于數據一致性，只要求數據在最后處理的狀態是一致的即可。如果在過程中發現錯誤，可以通過補償機制來進行處理，這樣使得錯誤數據能夠達到最終的一致性。

（7）基礎設施自動化。 隨著云計算服務與容器技術的不斷發展，運維基礎設施的工作變得越來越容易，但是當我們在實施微服務架構的時候，數據庫、應用程序雖然變都小了，但是因為拆分的原因，數量成倍增長，這也就使得運維人員不得不花費更多的時間去關注，且操作性任務也會成倍增長，如果這些問題一開始沒有引起足夠的重視，那么勢必會加重運維人員的工作負擔。

  因此，在微服務架構中必須從一開始就構建起“持續交付”平臺來支撐整個實施過程，一般來說都會包含兩個部分：自動化測試和自動化部署。

（8）容錯設計。 在單體應用中，一般不存在單個組件故障而其他組件還在運行的情況，通常都是一掛而全掛。但是在微服務架構中，由于各個服務都是運行在獨立的進程中，所以存在部分服務出現故障，而其他服務還正常運行的情況。舉個例子，假設運行正常的服務B調用發生故障的服務A時，由于故障服務A沒有返回，線程被掛起等待，直到超時才會被釋放，而此時若觸發服務B調用服務A的請求來自于服務C，而服務C頻繁調用服務B時，由于其依賴服務A，大量線程被掛起等待，最后導致服務A也不能正常服務，此時就會出現故障的蔓延。

  鑒于此種情形，在微服務架構中快速檢測出故障來源并盡可能的自動恢復服務是必須被設計和考慮的。一般來說，我們都希望在每個服務中實現監控和日志記錄的組件，然后提供諸如服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據的儀表盤等。

（9）演進式設計。 其實通過上面的學習，我們可以發現要實施一個完美的微服務架構，需要考慮很多東西且成本也挺大的，對于一些沒有過足夠經驗的團隊來說，極易可能付出比單體架構應用更多的代價。

  因此在很多情況下，架構師都會以演進的方式進行系統的構建，也就是說一個好的架構不是設計出來的，而是演進出來的。在初期，一般會以單體架構來設計和實施，一方面是因為系統初期體量不會太大，構建和維護成本都不高；另一方面初期的核心業務在后期通常也不會發生巨大的變化。隨著系統的發展或者業務的需要，架構師會將一些經常變動或者是有一段時間效應的內容進行微服務處理，并逐漸將原來在單體系統中多變的模塊拆分出來，而穩定不太變化的模塊就形成了一個核心微服務存在于整個架構中。

微服務技術

  接下來學習一些優秀企業分享的它們在微服務架構中針對不同應用場景出現的各種問題的各種解決方案和開源框架：

（1）服務治理：阿里巴巴開源的Dubbo和當當網在其基礎上擴展的DubboX、NetFlix的Eureka、Apache的Consul等；

（2）分布式配置管理：百度的Disconf、Netflix的Archaius、360的QConf、Spring Cloud的Config、淘寶的Diamond等；

（3）批量任務：當當網的Elastic-Job、LinkedIn的Azkaban、Spring Cloud的Task等；

（4）服務跟蹤：京東的Hydra、Spring Cloud Sleuth和Twitter的Zipkin等；

  當然上面列舉的只是一部分，對于有選擇困難癥的人來說，對于某一個問題存在多個答案的選擇也是一個問題。其實仔細看也就發現上面這些框架都是為了解決部分問題，那么問題來了其實完全可以選擇一個較為系統的工具，Spring Cloud就是這樣的工具，它是一個解決微服務架構實施的綜合性解決框架，它不是重復的造輪子，而是整合諸多被廣泛實踐和證明過的框架作為實施的基礎部件，然后在該基礎上創建了一些非常優秀的邊緣組件。

Spring Cloud簡介

  Spring Cloud是一個基于Spring Boot實現的微服務架構開發工具，它為微服務架構中涉及的配置管理、服務治理、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和集群狀態管理等操作提供了一種簡單的開發方式。

Spring Cloud包含了很多子項目，如下所示：

（1）Spring Cloud Config：配置管理，支持使用Git存儲配置內容，可以使用它來實現應用配置的外部化存儲，并支持客戶端配置信息刷新、加密/解密配置內容等；

（2）Spring Cloud Netflix：這是Spring Cloud的核心組件，對多個Netflix OSS開源套件進行整合：

• Eureka：服務治理組件，包含服務注冊中心、服務注冊與服務發現機制的實現；
• Hystrix：容錯管理組件，實現斷路器模式，幫助服務依賴中出現的延遲和為故障提供強大的容錯能力；
• Ribbon：客戶端負載均衡的服務調用組件；
• Feign：基于Ribbon和Hystrix的聲明式服務調用組件；
• Zuul：網關組件，提供智能路由、訪問過濾等功能；
• Archaius：外部化配置組件。

（3）Spring Cloud Bus：事件、消息總線，用于傳播集群中的狀態變化或事件，以觸發后續的處理，如用來動態刷新配置信息等；

（4）Spring Cloud Cluster：針對Zookeeper、Redis、Hazelcast、Consul的選舉算法和通用模式的實現；

（5）Spring Cloud Cloudfoundry：與Pivotal Cloudfoundry的整合支持；（6）Spring Cloud Consul：服務發現與配置管理工具；

（7）Spring Cloud Stream：通過Redis、RabbitMQ或者Kafka實現的消費微服務，可以通過簡單的聲明式模型來發送和接收消息；

（8）Spring Cloud AWS：用于簡化整合Amazon Web Service的組件；

（9）Spring Cloud Security：安全工具包，提供在Zuul代理中對于OAuth3客戶端請求的中繼器；

（10）Spring Cloud Sleuth：Spring Cloud應用的分布式服務跟蹤實現，可以完美的整合Zipkin；

（11）Spring Cloud Zookeeper：基于Zookeeper的服務發現與配置管理組件；

（12）Spring Cloud Starters：Spring Cloud的基礎組件，它是基于Spring Boot風格項目的基礎依賴模塊；

（13）Spring Cloud CLI：用于在Groovy中快速創建Spring Cloud應用的Spring Boot CLI插件。

當然絕對不只是這些組件，還有很多的組件等著我們去學習。