初識(shí)微服務(wù)（初識(shí)微服務(wù)架構(gòu)之springboot）

軟件開發(fā)過程中碰到什么問題

一個(gè)簡(jiǎn)單的應(yīng)用會(huì)隨著時(shí)間推移逐漸變大。在每次的sprint中，開發(fā)團(tuán)隊(duì)都會(huì)面對(duì)新“故事”，然后開發(fā)許多新代碼。幾年后，這個(gè)小而簡(jiǎn)單的應(yīng)用會(huì)變成了一個(gè)巨大的怪物。

一旦你的應(yīng)用變成一個(gè)又大又復(fù)雜的怪物，那開發(fā)團(tuán)隊(duì)肯定很痛苦。敏捷開發(fā)和部署舉步維艱，其中最主要問題就是這個(gè)應(yīng)用太復(fù)雜，以至于任何單個(gè)開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時(shí)。另外，團(tuán)隊(duì)士氣也會(huì)走下坡路。如果代碼難于理解，就不可能被正確的修改。最終會(huì)走向巨大的、不可理解的泥潭。

單體式應(yīng)用也會(huì)降低開發(fā)速度。應(yīng)用越大，啟動(dòng)時(shí)間會(huì)越長。比如，最近的一個(gè)調(diào)查表明，有時(shí)候應(yīng)用的啟動(dòng)時(shí)間居然超過了12分鐘。某些應(yīng)用需要40分鐘啟動(dòng)時(shí)間。如果開發(fā)者需要經(jīng)常重啟應(yīng)用，那么大部分時(shí)間就要在等待中渡過，生產(chǎn)效率受到極大影響。

另外，復(fù)雜而巨大的單體式應(yīng)用也不利于持續(xù)性開發(fā)。今天，SaaS應(yīng)用常態(tài)就是每天會(huì)改變很多次，而這對(duì)于單體式應(yīng)用模式非常困難。另外，這種變化帶來的影響并沒有很好的被理解，所以不得不做很多手工測(cè)試。那么接下來，持續(xù)部署也會(huì)很艱難。

單體式應(yīng)用在不同模塊發(fā)生資源沖突時(shí)，擴(kuò)展將會(huì)非常困難。比如，一個(gè)模塊完成一個(gè)CPU敏感邏輯，應(yīng)該部署在AWS EC2 Compute Optimizedinstances，而另外一個(gè)內(nèi)存數(shù)據(jù)庫模塊更合適于EC2 Memory-optimized instances。然而，由于這些模塊部署在一起，因此不得不在硬件選擇上做一個(gè)妥協(xié)。

單體式應(yīng)用另外一個(gè)問題是可靠性。因?yàn)樗心K都運(yùn)行在一個(gè)進(jìn)程中，任何一個(gè)模塊中的一個(gè)bug，比如memory leak，將會(huì)有可能弄垮整個(gè)進(jìn)程。除此之外，因?yàn)樗袘?yīng)用實(shí)例都是唯一的，這個(gè)bug將會(huì)影響到整個(gè)應(yīng)用的可靠性。

最后，單體式應(yīng)用使得采用新架構(gòu)和語言非常困難。比如，設(shè)想你有兩百萬行采用XYZ框架寫的代碼。如果想改成ABC框架，無論是時(shí)間還是成本都是非常昂貴的，即使ABC框架更好。因此，這是一個(gè)無法逾越的鴻溝。你不得不在最初選擇面前低頭。

總結(jié)一下：一開始你有一個(gè)很成功的關(guān)鍵業(yè)務(wù)應(yīng)用，后來就變成了一個(gè)巨大的，無法理解的怪物。因?yàn)椴捎眠^時(shí)的，效率低的技術(shù)，使得雇傭有潛力的開發(fā)者很困難。應(yīng)用無法擴(kuò)展，可靠性很低，最終，敏捷性開發(fā)和部署變的無法完成。

微服務(wù)解決應(yīng)用復(fù)雜性

面對(duì)上面的問題，通過采用微服務(wù)解決了上述問題。其思路不是開發(fā)一個(gè)巨大的單體式的應(yīng)用，而是將應(yīng)用分解為小的、互相連接的微服務(wù)。

一個(gè)微服務(wù)一般完成某個(gè)特定的功能，比如下單管理、客戶管理等等。每一個(gè)微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會(huì)發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。其它微服務(wù)完成一個(gè)WebUI，運(yùn)行時(shí)，每一個(gè)實(shí)例可能是一個(gè)云VM或者是Docker容器。

運(yùn)行時(shí)，行程管理服務(wù)由多個(gè)服務(wù)實(shí)例構(gòu)成。每一個(gè)服務(wù)實(shí)例都是一個(gè)Docker容器。為了保證高可用，這些容器一般都運(yùn)行在多個(gè)云VM上。服務(wù)實(shí)例前是一層諸如NGINX的負(fù)載均衡器，他們負(fù)責(zé)在各個(gè)實(shí)例間分發(fā)請(qǐng)求。負(fù)載均衡器也同時(shí)處理其它請(qǐng)求，例如緩存、權(quán)限控制、API統(tǒng)計(jì)和監(jiān)控。

這種微服務(wù)架構(gòu)模式深刻影響了應(yīng)用和數(shù)據(jù)庫之間的關(guān)系，不像傳統(tǒng)多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫，微服務(wù)架構(gòu)每個(gè)服務(wù)都有自己的數(shù)據(jù)庫。另外，這種思路也影響到了企業(yè)級(jí)數(shù)據(jù)模式。同時(shí)，這種模式意味著多份數(shù)據(jù)，但是，如果你想獲得微服務(wù)帶來的好處，每個(gè)服務(wù)獨(dú)有一個(gè)數(shù)據(jù)庫是必須的，因?yàn)檫@種架構(gòu)需要這種松耦合。

到底什么是微服務(wù)

接下來我們來看看到底什么是微服務(wù)。實(shí)際上微服務(wù)本身并沒有一個(gè)嚴(yán)格的定義，不過從很多人的反饋來看，大家都達(dá)成了這樣一個(gè)共識(shí)：微服務(wù)是一種簡(jiǎn)單的應(yīng)用，大概有10到100行代碼。我知道使用代碼行數(shù)來比較實(shí)現(xiàn)其實(shí)很不靠譜，因此你能理解這個(gè)意思就行，不必過分拘泥于細(xì)節(jié)。不過有一點(diǎn)需要注意，那就是微服務(wù)通常都是很小的，甚至是微型的。這意味著你不會(huì)在大型框架上看到很多小服務(wù)，這是不切實(shí)際的。簡(jiǎn)單與輕量級(jí)是當(dāng)今的主流。諸如Sinatra、Webbit、Finagle與Connect等小型框架在將你的代碼包裝到一個(gè)薄薄的通信層這方面做得剛剛好。

從物理角度來說，這些服務(wù)都很小，你可以在同一臺(tái)機(jī)器上運(yùn)行大量服務(wù)，不必?fù)?dān)心內(nèi)存或是資源等問題。重申一遍，基于大型框架的簡(jiǎn)單庫將會(huì)取得最后的勝利，你會(huì)發(fā)現(xiàn)對(duì)第三方庫的依賴越來越少。

這種服務(wù)層上的解耦還提供了另外一個(gè)有趣兒的選擇。我們將很多老舊應(yīng)用的復(fù)雜性推到了基礎(chǔ)設(shè)施層，不再受限于單個(gè)技術(shù)棧或是語言了。我們現(xiàn)在可以發(fā)揮出任何技術(shù)棧或是語言的優(yōu)勢(shì)。

你不會(huì)看到任何基于微服務(wù)的架構(gòu)是托管在應(yīng)用服務(wù)器上的，這是關(guān)鍵。本質(zhì)上，微服務(wù)是自我托管的，他們獲取一個(gè)端口然后**。這意味著你將失去典型的企業(yè)應(yīng)用服務(wù)器所帶來的很多好處，服務(wù)需要提供這些必要的功能（性能度量、監(jiān)控等等）。

微服務(wù)的通信

服務(wù)之間該如何通信呢？這個(gè)問題是無法通過一個(gè)簡(jiǎn)單的答案解決的，甚至在單個(gè)解決方案中也是難以做到的。最基本的答案就是通過HTTP公開所有服務(wù)，然后以JSON作為數(shù)據(jù)交換格式。服務(wù)探測(cè)（一個(gè)服務(wù)是如何找到另一個(gè)服務(wù)的）可以很簡(jiǎn)單，只需將端點(diǎn)細(xì)節(jié)信息放到配置文件中即可（硬編碼也行）。

你可能會(huì)發(fā)現(xiàn)在某些情況下，一個(gè)完整事務(wù)中對(duì)JSON負(fù)載的序列化與反序列化的代價(jià)會(huì)造成系統(tǒng)瓶頸。也許JSON并不適合，你可能需要使用別的協(xié)議，如Protobuf等。

不過硬編碼的URL會(huì)導(dǎo)致耦合。在分層應(yīng)用中，這是有意義的，不過對(duì)于基于服務(wù)的架構(gòu)來說，這意味著你不能再被這種潛在的限制所約束。服務(wù)之間的某些通信可以是完全解耦的，事實(shí)上，有些服務(wù)可以隨意發(fā)布事件或是數(shù)據(jù)。他們只是將其扔出去（比如說消息總線），也許有一天出現(xiàn)了某個(gè)服務(wù)，然后開始**了。此外，也許系統(tǒng)的某些部分會(huì)以批量/離線的流程進(jìn)行運(yùn)作，他們可能會(huì)在幾小時(shí)后才從隊(duì)列中取出消息。微服務(wù)架構(gòu)可以實(shí)現(xiàn)這種靈活性而無需修改整個(gè)架構(gòu)。

微服務(wù)的部署

部署一個(gè)微服務(wù)應(yīng)用也很復(fù)雜，一個(gè)分布式應(yīng)用只需要簡(jiǎn)單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個(gè)應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。相對(duì)比，一個(gè)微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成。例如，根據(jù)Adrian Cockcroft，Hailo有160個(gè)不同服務(wù)構(gòu)成，NetFlix?有大約600個(gè)服務(wù)。每個(gè)服務(wù)都有多個(gè)實(shí)例。這就造成許多需要配置、部署、擴(kuò)展和監(jiān)控的部分，除此之外，你還需要完成一個(gè)服務(wù)發(fā)現(xiàn)機(jī)制，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址(包括服務(wù)器地址和端口)。傳統(tǒng)的解決問題辦法不能用于解決這么復(fù)雜的問題。接續(xù)而來，成功部署一個(gè)微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法，并高度自動(dòng)化。

一種自動(dòng)化方法是使用PaaS服務(wù)，例如Cloud Foundry。?PaaS給開發(fā)者提供一個(gè)部署和管理微服務(wù)的簡(jiǎn)單方法，它把所有這些問題都打包內(nèi)置解決了。同時(shí)，配置PaaS的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實(shí)踐和策略來簡(jiǎn)化這些問題。另外一個(gè)自動(dòng)部署微服務(wù)應(yīng)用的方法是開發(fā)對(duì)于你來說最基礎(chǔ)的PaaS系統(tǒng)。一個(gè)典型的開始點(diǎn)是使用一個(gè)集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我們會(huì)看看如何基于軟件部署方法例如NGINX，可以方便的在微服務(wù)層面提供緩存、權(quán)限控制、API統(tǒng)計(jì)和監(jiān)控。

監(jiān)控與度量

分層解決方案的組件出現(xiàn)問題時(shí)不會(huì)銷聲匿跡，要么是編譯失敗，要么是遇到問題時(shí)拋出異常（除非你將拋出的異常隱藏掉了）。在基于服務(wù)的方式中，有的服務(wù)可能出現(xiàn)了問題，而其他服務(wù)則會(huì)很容易發(fā)現(xiàn)問題（特別是在pub/sub模型中）。這意味著我們必須要能對(duì)服務(wù)進(jìn)行監(jiān)控和編排。事實(shí)上，只知道服務(wù)還能用是不夠的，服務(wù)是不是還能提供業(yè)務(wù)價(jià)值？還能否繼續(xù)使用？它是可靠交易的瓶頸么？

監(jiān)控總是非常重要的事情，對(duì)于基于服務(wù)的架構(gòu)來說更是如此，因?yàn)檫@時(shí)出現(xiàn)的失敗并不容易被發(fā)現(xiàn)。JVM世界中的Metrics與Ostrich等庫不僅可以收集度量信息，還提供了與Nagios和Ganglia等服務(wù)的集成，可以將數(shù)據(jù)發(fā)送給他們。

微服務(wù)的測(cè)試

對(duì)于基于微服務(wù)架構(gòu)的系統(tǒng)來說，測(cè)試服務(wù)并沒有什么特殊之處，不過我這里要強(qiáng)調(diào)的是你不必再對(duì)每個(gè)服務(wù)使用完整的測(cè)試套件了。因?yàn)橐粋€(gè)服務(wù)只做一件事，因此引入系統(tǒng)Bug的幾率明顯降低了，這要?dú)w功于基于服務(wù)的系統(tǒng)的天生的行為。

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

微服務(wù)架構(gòu)模式有很多好處。首先，通過分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問題。在功能不變的情況下，應(yīng)用被分解為多個(gè)可管理的分支或服務(wù)。每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案，由此，單個(gè)服務(wù)很容易開發(fā)、理解和維護(hù)。

第二，這種架構(gòu)使得每個(gè)服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。當(dāng)然，許多公司試圖避免混亂，只提供某些技術(shù)選擇。然后，這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時(shí)采用的過時(shí)技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因?yàn)榉?wù)都是相對(duì)簡(jiǎn)單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

第三，微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對(duì)本服務(wù)的影響。這種改變可以加快部署速度。UI團(tuán)隊(duì)可以采用AB測(cè)試，快速的部署變化。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

最后，微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)獨(dú)立擴(kuò)展。你可以根據(jù)每個(gè)服務(wù)的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務(wù)資源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務(wù)，而在EC2 memory-optimized instances上部署內(nèi)存數(shù)據(jù)庫。

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

Fred Brooks在30年前寫道，“there are no silverbullets”，像任何其它科技一樣，微服務(wù)架構(gòu)也有不足。其中一個(gè)跟他的名字類似，『微服務(wù)』強(qiáng)調(diào)了服務(wù)大小，實(shí)際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務(wù)組。盡管小服務(wù)更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務(wù)的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署。

另外一個(gè)主要的不足是，微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會(huì)帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當(dāng)然這并不是什么難事，但相對(duì)于單體式應(yīng)用中通過語言層級(jí)的方法或者進(jìn)程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。

另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍。這種交易對(duì)于單體式應(yīng)用來說很容易，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個(gè)最終一致性的方法，從而對(duì)開發(fā)者提出了更高的要求和挑戰(zhàn)。

測(cè)試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的Spring Boot架構(gòu)，對(duì)一個(gè)單體式web應(yīng)用，測(cè)試它的REST API，是很容易的事情。反過來，同樣的服務(wù)測(cè)試需要啟動(dòng)和它有關(guān)的所有服務(wù)(至少需要這些服務(wù)的stubs)。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個(gè)挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)。比如，假設(shè)你在完成一個(gè)案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對(duì)比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對(duì)不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運(yùn)的是，許多改變一般只影響一個(gè)服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

微服務(wù)總結(jié)

微服務(wù)是一種新的架構(gòu)思路，從傳統(tǒng)的SOA中發(fā)揚(yáng)出來，摒棄了傳統(tǒng)SOA重型、低效的弊端。

微服務(wù)更多的是一種架構(gòu)理念，服務(wù)的劃分沒有一個(gè)強(qiáng)規(guī)則，遵循服務(wù)自治，數(shù)據(jù)自有即可。實(shí)施微服務(wù)同時(shí)也在踐行新的敏捷、devops等開發(fā)理念。

微服務(wù)適合復(fù)雜應(yīng)用，微服務(wù)就是為解耦復(fù)雜應(yīng)用誕生。復(fù)雜是業(yè)務(wù)邏輯復(fù)雜，并不是資源消耗多。所以微服務(wù)更適合應(yīng)用層業(yè)務(wù)的實(shí)施，而不是底層平臺(tái)，如存儲(chǔ)、數(shù)據(jù)庫、OS等。

微服務(wù)需要發(fā)展和配合更多的分布式監(jiān)控、部署、測(cè)試、定位工具，架構(gòu)的解耦同時(shí)引入了分布式的復(fù)雜性。

敏捷開發(fā) 企業(yè)應(yīng)用 DevOps web應(yīng)用開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。