目錄
一、單體架構(gòu)的問題
微服務(wù)為什么會出現(xiàn)？在學習Springboot的時候知道Springboot極大的簡化了我們的開發(fā)，我們可以快速的進行業(yè)務(wù)開發(fā)，Springboot單體應(yīng)用在項目的開發(fā)初期能夠滿足我們需求，這種單體架構(gòu)優(yōu)點非常的明顯：
容易測試：本地就可以起完整的系統(tǒng)，不需要外部依賴。
容易開發(fā)：我們只需引入依賴，選擇框架便可快速開發(fā)。
易于部署：單體架構(gòu)部署也較簡單，直接打包即可。
易于水平伸縮：這里的收縮時指當我們需要多個服務(wù)器時也比較方便
在項目剛開始的時候我們可以快速的開發(fā)，一個長壽的項目，需求不斷增加，原先的模塊也再不斷優(yōu)化，這個時候單體架構(gòu)的缺點開始顯現(xiàn)：
代碼膨脹，難以維護：代碼越來越多，開發(fā)人員也就越來越多，一旦出現(xiàn)bug，定位、修復成本很高，而且人員太多，代碼都放在一起，容易引起沖突，且由于業(yè)務(wù)集中在一起，業(yè)務(wù)復雜，很難全局把握，改一個bug可能會再多出兩個bug。
構(gòu)建、部署成本大：項目太大，構(gòu)建和部署就會非常慢，效率低下。
上手困難：互聯(lián)網(wǎng)企業(yè)人員更迭快，代碼過于集中，導致業(yè)務(wù)非常復雜，新人想要上手變得非常困難。
技術(shù)創(chuàng)新困難：代碼過于集中，我們很難使用到新技術(shù)，因為改動實在太大，容易出現(xiàn)問題。
可擴展性差：這里的可擴展性是指因為項目都必須部署在一臺服務(wù)器中，那項目所要的資源會越來越大，這樣我們只能擴展硬件（集群可以分散壓力，但是單個應(yīng)用所要的資源還是不能少的）。
二、微服務(wù)出現(xiàn)
微服務(wù)的出現(xiàn)就是為了解決這些問題，看看是如何解決的，微服務(wù)將系統(tǒng)拆分成一個個小服務(wù)（一般是按照模塊進行拆分，比如用戶服務(wù)、支付服務(wù)、訂單服務(wù)、出入庫服務(wù)等），那么即使業(yè)務(wù)量增加，我們也可以通過新增服務(wù)的形式來解決，這樣代碼就不會膨脹，構(gòu)建、部署也不是問題。由于服務(wù)不在一個框架中，那么我們可以很方便的對某一個服務(wù)進行技術(shù)創(chuàng)新，對一個服務(wù)的進行技術(shù)升級改動不會太大，而當我們有新技術(shù)產(chǎn)生時，我們就可以也可以應(yīng)用到新服務(wù)中。
微服務(wù)并沒有明確的定義，下面是一種比較通用的理解：
使用一套小服務(wù)來開發(fā)單個應(yīng)用的方式，每個服務(wù)運行在獨立的進程里，一般采用輕量級的通訊機制互聯(lián)，并且它們可以通過自動化方式部署。
通過定義我們可以知道微服務(wù)的特征：
微服務(wù)是由一系列的小服務(wù)共同組成的。
每個微服務(wù)都有自己獨立的進程。
每個服務(wù)都是獨立的業(yè)務(wù)開發(fā)，單一原則
每個服務(wù)都能獨立的部署（一般部署在容器中）。
微服務(wù)之間通過輕量級通信機制進行通信
分布式的管理。
三、微服務(wù)架構(gòu)圖
講到這里，對微服務(wù)的概念應(yīng)該有了一定的了解，下面畫的一個比較簡單的微服務(wù)架構(gòu)圖
圖中可以看出每個微服務(wù)都有自己獨立的數(shù)據(jù)庫，每個服務(wù)都會暴露自己的REST API 給外部調(diào)用，服務(wù)之間會存在互相調(diào)用關(guān)系，而每個服務(wù)都有可能被客戶端直接調(diào)用，另外我們看到還有一個API Gateway,這是統(tǒng)一個服務(wù)接口，它通?？梢杂幸韵伦饔茫?/p>
?1. 提供統(tǒng)一服務(wù)入口，讓微服務(wù)對前臺透明
?2. 聚合后臺的服務(wù)，節(jié)省流量，提升性能
?3. 提供安全，過濾，流控等API管理功能
四、優(yōu)缺點
凡是都有兩面性，一個技術(shù)也不可能只有優(yōu)點而沒有缺點，微服務(wù)的優(yōu)點很多，微服務(wù)的優(yōu)點其實就是單體架構(gòu)的缺點的反面，因為微服務(wù)本身就是來解決單體架構(gòu)問題的
獨立性：微服務(wù)從構(gòu)建、部署，擴容、縮容、甚至數(shù)據(jù)庫都是獨立的，服務(wù)只要管理好自己就可以，這樣就極大的降低了系統(tǒng)的復雜性。服務(wù)完全獨立獨立之后，從構(gòu)建到部署，到后期的擴容縮容都會變得簡單，基本就解決單體架構(gòu)上碰到的很多問題。
敏捷性：敏捷性是針對開發(fā)人員來講的，服務(wù)拆分之后，可以獨立專一開發(fā)，開發(fā)人員可以通過API快速的了解本服務(wù)的業(yè)務(wù)，互相之間并不影響。
技術(shù)棧靈活：微服務(wù)可以完全獨立的擁有技術(shù)棧，只需要保證提供的服務(wù)API不變，內(nèi)部使用何種技術(shù)棧很靈活。
高效的團隊：微服務(wù)的團隊會比較小，那溝通就會變得更加高效。
沒有最好的架構(gòu)，只有最適合的架構(gòu)，既然有這么多優(yōu)點，那缺點肯定也有不少
服務(wù)的拆分：服務(wù)如何拆分其實是非常重要且復雜的，服務(wù)拆分的太大或太小都不合適，這需要我們有非常豐富的經(jīng)驗，而這個在單體中是不存在的。
數(shù)據(jù)一致性：單體架構(gòu)中只有一個數(shù)據(jù)庫，我們可以通過事務(wù)解決多表之間數(shù)據(jù)的一致性，而在微服務(wù)中，每個服務(wù)中都有自己獨立的數(shù)據(jù)庫，要保證服務(wù)之間的數(shù)據(jù)一致性也是一個大的挑戰(zhàn)。
服務(wù)間通信成本：服務(wù)間互相通信也需要時間成本。
測試復雜性提高：服務(wù)之間存在依賴，那么測試時就必須啟動這些依賴，這就增加了復雜度。
運維部署復雜性提高：微服務(wù)應(yīng)用由大量服務(wù)組成，每個服務(wù)會起多個實例，要進行配置，部署，擴展和監(jiān)控。此外，還需要實現(xiàn)服務(wù)發(fā)現(xiàn)機制
五、技術(shù)點
要實現(xiàn)微服務(wù)，我們需要解決以下幾個技術(shù)點：
客戶端訪問服務(wù)：這個上面架構(gòu)圖中已經(jīng)給出，使用API Gateway。
服務(wù)通信：服務(wù)與服務(wù)之間的通信有兩種方式，同步與異步：
同步通信中又分為兩種：Http與RPC，http訪問很好理解，相信一般的系統(tǒng)也會調(diào)用外部的一些服務(wù)，這些基本都是使用http,因為http可以跨語言，跨客戶端，相對使用較廣，如http Client ,而RPC也有自己的優(yōu)點，首先是效率更高，更安全可控，特別是內(nèi)部服務(wù)互相調(diào)用時，用統(tǒng)一的RPC框架，服務(wù)的侵入性更低，調(diào)用服務(wù)甚至就像調(diào)用自己的服務(wù)一樣簡單,如dubbo（注：dubbo只能使用java語言）。
異步通信是通過消息隊列來實現(xiàn)，異步通信的好處是可以降低服務(wù)之間的耦合，有削峰的好處，而且使用消息隊列可以方便的實現(xiàn)數(shù)據(jù)的最終一致性。
服務(wù)治理：為了服務(wù)的高可用，微服務(wù)一般都有多個拷貝，做負載均衡，而這個時候就必須知道服務(wù)的狀態(tài)，一個服務(wù)隨時有可能下線，下線之后后續(xù)有可能重新啟動，這些都需要我們一個服務(wù)治理功能，也即是服務(wù)的注冊與發(fā)現(xiàn)。
? ? ? ? 產(chǎn)品服務(wù)啟動了三個，他們都會去注冊中心進行注冊，注冊成功后，會通過心跳包告訴注冊中心是否在線或者下線，而訂單服務(wù)要去調(diào)用產(chǎn)品服務(wù)，會先去注冊中心進行查詢，查詢出相應(yīng)的地址然后再去調(diào)用產(chǎn)品服務(wù)。
服務(wù)崩潰處理：在運行期間會出現(xiàn)服務(wù)崩潰的情況，比如網(wǎng)絡(luò)原因，阻塞原因，這個時候服務(wù)并不是下線，還是能夠被找到，我們必須妥善要進行處理，否則可能會導致整個系統(tǒng)的崩潰，處理的方式有：
重試機制
熔斷機制
降級機制
限流機制
六、解決方案
以上都是微服務(wù)的一些概念，既然有天上飛的概念，就有落地的實現(xiàn)，現(xiàn)在主流的微服務(wù)架構(gòu)有兩套解決方案：Dubbo+Zookeeper與SpringCloud。
我司現(xiàn)在兩種方案都在用，總體來說兩種方案都可以很方便的進行微服務(wù)開發(fā)，其中的區(qū)別在于SpringCloud組件多，功能完備，全家桶式，基本微服務(wù)中會遇到的問題都有相應(yīng)的解決方案，在通信方面SpringCloud使用的是http。
而Dubbo+Zookeeper使用的是RPC，組件較少，功能非完備（但是我們可以自己去找相應(yīng)的解決方案），并且現(xiàn)在交由Apache進行孵化，后面應(yīng)該會實現(xiàn)功能的完備。
就個人來說，認為Dubbo+Zookeeper的侵入性更少，且調(diào)用過程更簡單，更加類似服務(wù)之間的調(diào)用，兩種方案后續(xù)就會進行學習。
寫在最后：
碼字不易看到最后了，那就點個關(guān)注唄，只收藏不點關(guān)注的都是在耍流氓！
關(guān)注并私信我“架構(gòu)”，免費送一些Java架構(gòu)資料，先到先得！
