微服務(wù)中的一些知識點總結(jié)

微服務(wù)架構(gòu)

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

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

與單體系統(tǒng)的區(qū)別

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

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

微服務(wù)帶來的挑戰(zhàn)

  在實施微服務(wù)之前，有必要知道因為微服務(wù)的拆分而引發(fā)了諸多原本在單體應(yīng)用中沒有的問題和挑戰(zhàn)：

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

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

（3）分布式的復(fù)雜性。 由于拆分后的各個微服務(wù)都是獨立部署并運行在各自的進程內(nèi)，它們只能通過通信來進行協(xié)作，所以分布式環(huán)境的問題都是微服務(wù)架構(gòu)設(shè)計時需要考慮的重要因素，如網(wǎng)絡(luò)延遲、分布式事務(wù)、異步消息等。

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

微服務(wù)9大特性

  由于存在環(huán)境、資源、團隊等各種因素的影響，因此架構(gòu)師在對一個大型系統(tǒng)架構(gòu)的設(shè)計與實施過程中幾乎不會出現(xiàn)完全相同的架構(gòu)設(shè)計。對于微服務(wù)架構(gòu)而言更是如此，由于微服務(wù)架構(gòu)只是一種建議，不是硬性規(guī)定，因此架構(gòu)師通常會根據(jù)自身理解和實際情況來進行設(shè)計，并在發(fā)展的過程中不斷演進和完善。當(dāng)然了，俗話說的好，不以規(guī)矩?zé)o以成方圓，因此非服務(wù)架構(gòu)存在9大特性，通過這9大特性的學(xué)習(xí)，對于架構(gòu)師設(shè)計架構(gòu)有著指導(dǎo)性意義。

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

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

  在微服務(wù)架構(gòu)的實施時，需要采用不同的團隊分割方法。由于每一個服務(wù)都是針對特定業(yè)務(wù)的寬?；蛘呤侨珬崿F(xiàn)，既要負責(zé)數(shù)據(jù)的持久化存儲，又要負責(zé)用戶的接口定義等各種跨專業(yè)領(lǐng)域職能。因此在面對大型項目的時候，對于微服務(wù)團隊的拆分筆者建議按照業(yè)務(wù)線的方式進行拆分，一方面可以有效的減少服務(wù)內(nèi)部修改所產(chǎn)生的內(nèi)耗；另一方面團隊的邊界變得更加清晰。

（3）做產(chǎn)品的態(tài)度。 在實施微服務(wù)架構(gòu)的團隊中，每個小團隊都應(yīng)該是以做產(chǎn)品的方式對其產(chǎn)品的整個生命周期負責(zé)，而不是以項目的模式，以完成開發(fā)與交互并將成果交給維護者為最終目標。

  一般來說，開發(fā)團隊通過了解服務(wù)在具體生產(chǎn)環(huán)境中的情況，可以增加他們對于具體業(yè)務(wù)的理解，所以需要開發(fā)者用做產(chǎn)品的態(tài)度來對待每一個微服務(wù)，持續(xù)關(guān)注服務(wù)的運作情況，并不斷分析以幫助用戶來改善業(yè)務(wù)功能。

（4）智能端點與啞管道。 在單體應(yīng)用中，組件之間可以直接通過函數(shù)調(diào)用的方式來進行交互協(xié)作；而在微服務(wù)架構(gòu)中，由于服務(wù)不在一個進程中，因此組件的通信模式發(fā)送了變化，如果僅僅是將原本在進程內(nèi)的方法調(diào)用改成RPC方式的調(diào)用，這樣會導(dǎo)致微服務(wù)之間產(chǎn)生繁瑣的通信，使得系統(tǒng)表現(xiàn)更為糟糕，因此我們需要更粗粒度的通信協(xié)議。

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

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

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

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

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

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

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

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

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

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

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

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

（9）演進式設(shè)計。 其實通過上面的學(xué)習(xí)，我們可以發(fā)現(xiàn)要實施一個完美的微服務(wù)架構(gòu)，需要考慮很多東西且成本也挺大的，對于一些沒有過足夠經(jīng)驗的團隊來說，極易可能付出比單體架構(gòu)應(yīng)用更多的代價。

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

微服務(wù)技術(shù)

  接下來學(xué)習(xí)一些優(yōu)秀企業(yè)分享的它們在微服務(wù)架構(gòu)中針對不同應(yīng)用場景出現(xiàn)的各種問題的各種解決方案和開源框架：

（1）服務(wù)治理：阿里巴巴開源的Dubbo和當(dāng)當(dāng)網(wǎng)在其基礎(chǔ)上擴展的DubboX、NetFlix的Eureka、Apache的Consul等；

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

（3）批量任務(wù)：當(dāng)當(dāng)網(wǎng)的Elastic-Job、LinkedIn的Azkaban、Spring Cloud的Task等；

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

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

Spring Cloud簡介

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

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

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

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

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

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

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

（5）Spring Cloud Cloudfoundry：與Pivotal Cloudfoundry的整合支持；（6）Spring Cloud Consul：服務(wù)發(fā)現(xiàn)與配置管理工具；

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

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

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

（10）Spring Cloud Sleuth：Spring Cloud應(yīng)用的分布式服務(wù)跟蹤實現(xiàn)，可以完美的整合Zipkin；

（11）Spring Cloud Zookeeper：基于Zookeeper的服務(wù)發(fā)現(xiàn)與配置管理組件；

（12）Spring Cloud Starters：Spring Cloud的基礎(chǔ)組件，它是基于Spring Boot風(fēng)格項目的基礎(chǔ)依賴模塊；

（13）Spring Cloud CLI：用于在Groovy中快速創(chuàng)建Spring Cloud應(yīng)用的Spring Boot CLI插件。

當(dāng)然絕對不只是這些組件，還有很多的組件等著我們?nèi)W(xué)習(xí)。