微服務架構 - 正確的開始

　　前言

　　微服務自從Fred George提出，後續逐漸由不一樣的大師如Martin Fowler，Neal Ford等人接力推廣演進後，已經在業界如火如荼的流行了好些年，它的目的是有效的拆分應用，實現敏捷開發和部署 。

　　借用Martin Fowler的話說：

　　微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。

　　每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相協做（一般是基於HTTP協議的RESTful API）。

　　每一個服務都圍繞着具體業務進行構建，而且可以被獨立的部署到生產環境、類生產環境等。

　　從這裏面咱們能夠看出，這裏面的關鍵字是「小」，「獨立」，「輕量級」，從中咱們能夠總結爲：服務之間是鬆耦合的，不相互影響的。但「小」絕對不是字面上理解的小，咱們下面將介紹一個服務的小的維度是什麼。

　　單體服務　　

　　提到微服務，就不能不提到單體應用了，咱們一般所說的單體應用，即將全部功能都打包成在一個獨立單元的應用程序。

　　一個典型的單體應用就是將全部業務場景的表示層、業務邏輯層和數據訪問層放在一個工程中，最終通過編譯、打包，部署在一臺服務器上。

 　　在微服務或者SOA架構沒提出來以前，業界應該基本都是單體應用，分佈式系統架構在業界內已經有較長的歷史了，但單體應用仍是佔據着大半壁江山。

　　存在即合理的

　　因此存在的東西都具有本身的優勢，咱們來看一下單體應用的優勢。

　　優勢

• 開發方便：集中式管理，只須要在一個解決方案中編程和構建
• 測試相對簡單：只須要寫一些端到端的測試用例，啓動便可總體聯調查找問題
• 部署手段簡易：只須要把一份構建好的文件丟上服務器
• 容易橫向擴展：能夠部署多個實例，由負載均衡器調度便可
• 沒有分佈式的管理/調用開銷

　　這些優勢是顯著的，它們能給人帶來明確的掌控感受，而不是不可控的飄渺虛無感。

　　然而，它的缺點也是很是明顯的，想一想咱們如今大部分的項目，伴隨着愈來愈快的互聯網信息時代，業務要的就是靈活變更和快速上線，針對於靈活和快速，單體應用是沒法提供的。

　　缺點

• 開發效率低：系統龐大複雜，沒人能理解所有，且全部的開發在一個項目改代碼，代碼衝突不斷
• 代碼維護難：代碼功能耦合在一塊兒，牽一髮動全身
• 部署不靈活：構建時間長，任何小修改必須從新構建整個項目，這個週期每每很長
• 穩定性不高：系統缺少故障隔離，一個微不足道的小問題，能夠致使整個應用掛掉 

　　能夠確定的是，一旦你的應用變成一個又大又複雜的怪物，那開發團隊確定很痛苦。敏捷開發和部署舉步維艱，每次的開發都會引出其餘問題，由於它們的耦合性太強了。

　　其中最主要問題就是這個應用太複雜，以致於任何單個開發者都不可能搞懂它。所以，修正bug和正確的添加新功能變的很是困難，而且很耗時。

　　另外，團隊士氣也會走下坡路。若是代碼難於理解，就不可能被正確的修改，最終會走向巨大的、不可理解的泥潭。

　　因此在這時，不少人把目光投向了微服務。

　　微服務　　

　　由來

　　首先任何的技術不會無緣無故的出現，它們的出現，是某些痛點一直在困擾着大多數人，因此這些技術的出現，都是有特定背景的。

　　從上面來看，有訴求才會有發展，沒有單體式應用的痛點折磨，沒有分佈式系統的鋪墊，沒有自動化工具的應用，是不可能出現所謂的微服務的，因此咱們能夠說，微服務架構是演進過來的。

　　微服務是一種架構風格

　　微服務在Chris口中，是一種架構設計風格，而在國內，更多的開發者視之爲具體的某個服務，因此咱們一般的說法是「一個微服務」，按照Chris本身的說法，系統是採用了微服務架構設計風格，由若干個服務構成，這纔是一個完整的微服務。

　　「微」服務

　　微服務這個術語讓咱們不少人錯誤的將關注點聚焦在「微」上，它暗示着咱們服務的顆粒度是應該很是小的。

　　實際上，大小不是一個重要的考慮因素。

　　細想一下微服務的進化鋪墊，咱們爲何要拆服務？是因爲單體應用的臃腫龐大且耦合性太高的特性。因此咱們在拆分的過程當中，更多的考慮方面是在如何避免單體應用的耦合問題，否則拆出來的同樣是一個相互牽扯的單體微應用，因此咱們的關注點應該是在每一個服務的鬆散耦合上，肯定好它的邊界，讓每一個服務能作到真正的鬆耦合，而不只僅是大小問題。

　　誠然，小服務確實是維護性更高。但咱們微服務的目標，更多的是定義咱們的工做方式，好比定義爲可由小團隊自主開發，而且交付時間短，與其餘團隊協做少，不會相互影響的工做方式。

　　因此咱們服務的設計和定義，需遵循咱們的目標法則去規劃的，而這個法則就是服務內的高內聚和服務間的低耦合。

　　微服務架構經過把一些小的，鬆耦合的服務組織在一塊兒，從新定義了咱們的應用，這樣的結果是提高了咱們開發階段的效率，特別是可維護性，可測試性和可部署性，經過這樣的方式影響着團隊的效率提高。

 　　服務的本質

　　每一個構成微服務架構體系的服務，本質都是一個可獨立運行的應用程序。

　　這個服務是由一組邊界清晰，高內聚的職責組成，並且它能夠作本身的負載均衡，獨立部署，獨立發佈，可以快速脫離單體應用的侷限性快速上線。

　　這也是微服務的優點所在，只要作到接口兼容或者版本兼容，沒必要作過多的服務依賴。  

　　優勢

　　微服務的優勢衆多，但我認爲它最重要的是改變着咱們的工做方式，如：

• 更加契合敏捷開發

　　咱們知道，敏捷開發這種軟件工程方法已經在不少公司中採用了，敏捷開發的意義在於更快速的交付可運行版本以及迭代作功能最小閉環，它是這個信息時代的必然產物。當咱們採用微服務時，在團隊自治的同時，意味着更快速的開發和交付。

　　敏捷開發帶來的不只僅是開發模式上的改變，也帶來了組織結構的變化，衍生出更多的小團隊自治，小團隊實施敏捷開發，帶來更快的功能迭代和獨立發佈，即便出現問題也不會影響整個應用。

• Devops文化的推廣

　　在Neal Ford的微服務理念中，Microservices are the first post DevOps revolution architecture，DevOps所涵蓋的一系列文化和理念，是微服務演進過程當中必不可少的先決條件。

　　微服務的流行，更好的推進了Devops文化，它們是相輔相成的。　　

　　比較肯定的說，在傳統的運維模式下，是很難有效實現微服務架構的，由於微服務在治理層面須要自動化基礎設施、自動化部署、自動化驗證、以及利用有效的工具完成運維、監控、告警等。而只有將DevOps與微服務緊密的結合起來，才能達到事半功倍的效果。

• 技術棧的選擇

　　當咱們採用單體服務時，它所使用的編程語言就已經肯定了，但微服務支持使用不一樣的語言開發，容許你選擇合適的技術棧。

　　咱們的企業發展能存活的根本是什麼？就是能賺錢才能活下去，換言之也就是對成本的控制。當咱們可以採用適合本身的成本投入方式，在各個環節和服務採用最合適的技術棧，可以給企業的投入成本作必定的保障。 

• 組織結構的變化

　　組織結構變化會給咱們帶來什麼好處？

　　其實咱們一直在暗示着，服務的職責要單一，作到專，然而這個專並不只僅在服務的職責層面上，還有在組織結構上， 微服務勢必會影響到咱們的中臺戰略能力，因此咱們更須要不一樣的組專一於不一樣的技術和業務。

　　簡單點說，讓專業的人作專業的事！這樣才能更好的提升總體的生產效率，而不是事事都有牽絆。

• 雲生態下的新技術衝擊

　　這個彷佛並非優勢，但我相信對不少人來講，這又確切是個優勢，由於這些技術對全部有技術抱負的人來講，造就了一個很好的時代。　　

　　當咱們採用微服務時，目光已經不能僅侷限於應用層面的開發了，容器化，服務編排工具，服務網格，雲原生等新生的技術，讓咱們知道如何更好的治理好本身的服務羣，支撐本身的服務更好的擴展。　　

 　　挑戰

• 　微服務本質上是分佈式系統，因此在分佈式系統中遇到的難點，在微服務中都會遇到，分佈式系統進程間的通訊保證，網絡開銷以及事務處理歷來都是難題
• 　微服務的流行，離不開容器化和雲生態，離不開gRPC，ServiceMesh，雲原生等新技術的崛起以及實際生產應用。換言之，你須要瞭解乃至熟知這些技術，畢竟傳統的單體應用只須要更多的專一於應用層面
• 　微服務架構帶來過多的運維操做，須要團隊具有必定的 DevOps 技能，在運維層面開銷會很大
•    治理中心（包括基礎設施架構，集合着CICD，監控等微服務必要的非功能性需求）
•    測試將會是很是難，由於它再也不是端到端，還很大可能會存在多版本的不一樣服務帶來不一樣的測試場景

　　這些挑戰，分析一下本質，就是對人的要求更高了，因此說採用微服務並不只僅是技術層面帶來的衝擊，更多的是對人帶來的思想/能力衝擊。

　　微服務的解剖

　　在實踐微服務的過程當中，能夠劃分爲三部曲：

1. 服務劃分
2. 服務開發
3. 服務治理

　　這三部也是涵蓋了微服務架構落地的所有步驟，每一步都會有不一樣的指導方法論用於區別於傳統的開發思想，後續將會基於這些步驟結合流行的方法學來指導咱們服務落地。

　　總結

　　微服務不是銀彈！ 

　　我特別喜歡說的一句話是：任何的技術，都是有適用場景的。因此我很喜歡看到那些能基於目前的痛點以及中長期的發展所面臨的問題分析， 對比單體架構和微服務架構帶來的收益比。

　　咱們須要的是思考技術能帶來的價值，而不是爲技術瘋狂。

　　任何的技術手段，都是用來服務業務的，能支撐業務創造價值的，纔是好技術，不然這些技術一文不值。

　　無論黑貓白貓，捉到老鼠的就是好貓！　　

　　微服務架構也不例外。

　　因此當你想要採用微服務時，問一下本身這些問題：

• 爲何團隊想要採用微服務？採用後團隊將能獲得什麼？（說明充分了解了單體/微服務的優缺點，並能清晰瞭解到業務以及團隊在中長期所面臨的問題點）
• 是否組織結構以及文化底蘊有必定的支撐？（團隊是否能經得起微服務所帶來的衝擊）
• 是否有必定的技術基礎支撐？（說明能對微服務的所面臨的技術挑戰有了必定的認識）　

　　當你能作到對以上問題都有清晰答案後，且仍然決定採用微服務架構，說明你已經對微服務所帶來的收益比有了本身的判斷。　

　　Last but not least

　　在將組織推向微服務道路以前，最重要的決策人理解了「爲何是微服務」，而不是「爲何不是微服務」。