hi，這里桑小榆，
本篇，我們開始探討微服務架構這塊內容，并打算專門寫一個微服務的專欄，寫微服務的知識體系其實早有動機，把微服務架構知識梳理完整，由于很多因素沒能開展開來，所以一直擱置了，
這次，我繼續持大道至簡的思想，來探討微服務架構的全面內容，盡管我們在實際作業中并沒有用到這塊內容，本職本分或許是螺絲釘角色，但微服務的熱門程度以及發展趨勢，迫切使你很有必要了解這塊內容，并當作知識儲備起來，也許有朝一日在面試中或者和碼友談論時也能夠有些觀點，
我們先不直接引出微服務的概念，我們先了解一下軟體架構的演進，畢竟了解一個事務最好的出發點是了解它的背景，由來以及發展，為后續了解微服務更加的得心應手，
單體架構
在早期90年代互聯網發展中，產生了軟體工程，并催生了以C語言為代表的面向物件的高級語言，同時，單體架構也由此產生，我相信從事it行業的小伙伴對單體架構并不陌生，當時軟體概念還沒普及，面對需求更多以一個單體專案開發的功能模塊，所有的代碼邏輯耦合在一起，一兩個人就可以負責所有的功能業務開發，對于當時的用戶使用量來說，單體架構足夠應付，
單體架構的方式，直接干練，到目前為止使用量也不在少數，畢竟這種架構方式也符合人類便捷思維的一種方式，類似的提出面向物件思想之前，使用的面向程序思想，一個功能按照有序的順序一步步撰寫有序呼叫，這也是人們傾向的思考思維，
很明顯，我們能夠看到單體架構的優勢：
易于開發，直接使用開發工具創建一個專案即可入手開發，
易于部署，開發完之后，直接打包部署在適應的服務器，例如：apache，iis，tomcat等，
易于擴展，需要擴展的功能我們也可以直接下手開發，甚至可以將專案打包多份運行在多臺服務器實作負載均衡，
然而，以現在用戶使用量的角度來看單體架構，它的弊處也隨處可見，
龐大的單體代碼庫，會嚇倒自己和同事，也會嚇跑新手，一時接手也需要花不少時間去逐個理解，單體架構龐大之后沒有清晰的模塊劃分，可能會隨著時間推移，且每個人代碼習慣也會面臨不一樣，導致模塊被分解，整體代碼變得越來越難理解，代碼的質量也逐漸下降，也就是我們俗稱的“shit mountain，”誰碰誰倒霉！
IDE過載較大，面臨成堆的代碼量，你可能早上高興上班，啟動專案的時間就已經喝了兩杯咖啡了，或許新同事的不正確操作引來一堆紅色警告，上午時間沒了，血壓也上去了，
持續部署的困難，面臨大型單體應用程式，剛開始開發完很順利，部署也很順利，然而，產品經理每次經過你的崗位，面帶微笑，提了一堆需求給你，今晚改完發布，
改完之后你需要重新部署整個應用程式，有時還得先中斷其他后臺任務，無論受不受你當前更改的影響，最終導致問題的概率會增加，
或許因為新需求改動了組件，一部署即error警告，此時整個專案便無法運行,或許你在代碼里不小心寫了一行讓cpu飆升的代碼，導致服務器宕機整個服務也無法使用了，真讓人頭大，
擴展應用程式可能變得困難，單體架構擴展只能在本身程式里擴展，我們雖然可以通過復制部署到多臺服務器或者云服務來部署實作負載均衡，并根據負載數量來調整實體數量（也就是拷貝部署多少個服務），
但是在與資料互動時，所有服務始終都是使用一個資料庫訪問所有資料，這很顯然降低了快取效率并增加了記憶體消耗和IO流量，也就是資料訪問量上來了，本該走快取了卻直接跑去訪問資料庫，大量訪問資料庫的同時需要頻繁調度記憶體以及頻繁輸送資料，這將會是很糟糕的情況，
擴展開發的障礙，單體應用也會阻礙擴展開發，到了一定規模之后，我們很難將UI，商品，庫存分開獨立開發，都將在一個應用程式里開發，任何一個出問題或者拖延了開發周期都將會影響到整個的服務，團隊也將必須協調開發作業和重新部署，
需要對技術堆疊做出長期承諾，開發單體程式被迫使你在開發之初時選擇的技術堆疊要保持一致，如果我們當初選擇了C#開發，那么后期想使用Go開發，那么將會是一件困難的事情，因為單體程式很難兼容其他的技術堆疊使用，要么將選擇重構，面對龐大的單體程式重構一堆“shit mountain”將會面臨不小的挑戰，
說了單體應用的諸多缺點，并不是我在找茬，它本身不是缺點，是在于面對型應用和超大型應用的出現（單純應用的龐大，用戶數并不龐大），以及用戶量劇增時體現出來的不適用性，迫切需要新的且適應的架構方式來解決我們的麻煩，
垂直架構
于是,垂直架構出現了，也成為豎井式架構，可能有伙伴沒聽過垂直架構，這也是架構演進的一種必然趨勢，面對單體架構的不足，架構師們很顯然會從單體架構里按照業務做垂直劃分成多個單體應用，此時由原來的單體應用變成了多單體應用部署，所謂的垂直就是在一個應用里，根據業務來劃分獨立的模塊，每個業務模塊做專一的事情并沒有直接的關聯，
將龐大的系統進行劃分多個單體應用，可以很好地實作流量分擔，解決一定程度的并發問題，
可以針對不同模塊進行優化，將減少因為一個改動影響整個系統的麻煩，
更加方便水平擴展，也就是多個單體里每個單體拷貝副本部署到多個服務器里，更好地實作負載均衡，容錯率也顯著提高，
單體之間相互獨立，互不影響，針對不同模塊進行優化，不會因為一個組件或者一個error導致整個系統崩潰，面對新增業務的迭代更加高效，
然而，雖然是將一個單體拆分為多個單體，但是必然需要服務之間互相呼叫，如果某個服務的埠或者ip發生改變，呼叫的系統也需要手動更改，偏向硬編碼，
搭建集群時，我們拆分的多個單體應用并拷貝副本部署多套服務搭建在一起共同作業，集群之后看似一個完整的個體應用實則內部多個節點互相協同負載作業均衡，但是，垂直架構的集群將會面臨內外網負載的問題，遷移機器時影響呼叫方的路由，導致路徑故障無法正常使用，
服務之間的呼叫方式存在不統一，基于httpclient，webservice等介面的協議不統一，
服務監控不夠健全，除了依靠埠、行程監控這些能夠提供監控，其余呼叫的成功率、失敗率、耗時等等指標性的是沒有的，
所以面對現有的瓶頸，且伴隨互聯網的急劇發展，應用的使用逐漸普及挨家挨戶，用戶規模呈指數級增長，垂直架構雖然能夠應付應用的龐大，但是很難滿足承載海量用戶的需求，并且隨著分布式理論和分布式技術的日漸成熟，面向服務架構（SOA）開始出現，并廣泛應用于大型的系統上，
面向服務架構
面向服務架構（SOA），可以理解為一個組件模型，將應用程式按照不同功能單元（稱為服務）進行拆分，使得這些服務之間定義良好的介面和協議聯系起來，
它的宗旨在于將程式或軟體組件構建為服務，提供一種發布可用服務機制，包括它們的功能和輸入輸出（I/O）要求，并且控制這些服務的正常使用以及避免安全和治理問題，
看到這里，你會發現面向服務架構對于應用的拆分相比于垂直機構的拆分，顆粒度粗細上明顯細了一個量級，
面向服務架構的模式主要有兩種，一種是企業服務總線（ESB）為代表的SOA，另一種是RPC為代表的SOA，
企業服務總線（ESB），是一種模式，當我們通過SOA按照不同功能進行拆分的多個服務，然后我們搭建一個訊息總線，來連接這些拆分的各個服務，所有的服務產生的訊息都需要經過訊息總線，通過訊息總線來進行轉化、解釋以及路由作業，達成了一種以訊息總線為中心的服務通訊的協議，
RPC（remote procedure call）遠程程序呼叫，也就是本地呼叫一個函式或者物件方法，實際上是呼叫了遠程服務器上的函式和方法，這也很好理解，我們劃分了多個一定顆粒的服務，此時是游離且獨立的，我們需要使得這些服務具備互相通訊的功能，我們會想到http或者webservice來進行通訊，也是rpc思想的一種體現，http雖然具備完整的通訊體系和標準的規范，但是滿足不了企業的內網和外網之間日益復雜的資訊互動，所以現如今成熟的prc框架也有不少，可以拿來使用，例如：阿里巴巴開源的Dubbo，微博開源的Motan，騰訊開源的Tars，國外Pivotal公司開源的SpringCloud，谷歌開源的gPRc,facebook開源的Thrift等，這里不再展開講解框架的內容，有興趣伙伴可各自翻閱相關資料，
相比于ESB和RPC這兩種模式，由于ESB的初始搭建需要一定的人力物力，以及面對持續高漲的資料通訊壓力而難以追蹤，人們更加傾向于使用RPC模式，可以直接參考標準的http來通訊，或者使用開源的框架，
我們可以看到面向服務架構（SOA）的優點：
可重用性高，由于一個個服務具備獨立且規范的restful風格，我們不再需要重構或者考慮它的底層技術堆疊如何，
易于維護，因為所有的服務都是相互獨立的，因為我們可以輕松應對后期的修改和更新，不會影響到其他服務，很好地降低了組織的運營成本，
促進互操作性，我們使用標準化的通訊協議使得平臺能夠輕松地在客戶端與服務之間傳遞資料，無需考慮它們所構建的語言是什么，
高可用性，我們可以很好的提供服務的可用性，服務的獨立增加系統的容錯率，通過集群可以大大的提高服務的可用性，
高可靠性，SOA架構能夠生成可靠的應用程式，因為除錯小型服務要比除錯大型服務要方便的多，
可擴展性，SOA架構使得服務可以在不同的服務環境運行，從而提高了可擴展性，此外，使用標準通訊協議允許組織降低客戶端和服務器之間的互動級別，降低互動級別允許在不增加額外的壓力情況下進行擴展應用程式，
但是SOA的架構的ESB模式由于本身存在復雜性，和internet的restful api模型也不兼容，且面對高漲的資料通訊一時也難以捕捉和追蹤，
SOA架構的初期實施也需要大量的人力和物力的投資，
服務管理很復雜，因為服務交換了數百萬條資料難以跟蹤訊息，
每次服務通訊時都會驗證服務的輸入引數，從而降低性能并增加負載和相應時間，
總結
發展到SOA時，更多的使用這些架構的驅動力是業務推動的，由于restful（統一介面服務原則）的出現，人們更為廣泛接受這個模式，將廣泛的“服務”概念轉換為“軟體流程”而不是“業務流程”，并且以軟體架構為中心的趨勢，也就是說我們常說的微服務，微服務對于服務的分解更為多樣，比如我們可以根據業務能力拆分、子域拆分、獨立服務，按照團隊等，
當然這些思想將會在后續逐一探討，本篇主要以服務架構的演進為主，
縱觀以上服務架構演進的歷程，我們很容易發現軟體架構演進的規則，那就是一個字：拆！從一個單體應用拆分為多個單體，再進行拆分，拆分為眾多的小型服務，最終拆分成一個個細微且獨立的服務，每個獨立的服務擁有高度自治的能力，這也是去中心化的體現，
好了，軟體架構的發展部分就到這了，如果有興趣對文中提到的技術堆疊感興趣也可去多了解，接下來我們一起推進微服務，認識微服務到底是啥，
拋一個網路出現的一個話題：領導說把服務拆分開來，就是在做微服務，對此你怎么看呢？
喜歡的話，點個??也是支持~
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/513103.html
標籤：架構設計