架構師曰：微服務真不是企業必須，但你不會還不行，你說氣人不？職場頭條網

架構師曰：微服務真不是企業必須，但你不會還不行，你說氣人不？

微服務，相當火的一個概念，從小到大，所有的公司都在往微服務上靠攏，在面試的時候，微服務相關的技術也是在簡歷上可以說是標黑出來的重點，但是，這些所謂的從使用微服務的公司出來的人，當具體問到一些實際的問題是如何解決的時候，臉上的表情不得讓人深思，於是，在機緣巧合之下，我和一個確定可以發offer的面試者聊了一下，卻發現了一個很嚴重的問題，他所在的公司，在微服務這一塊，“有名無實啊”，面試的時候造航母，可實際工作，連擰螺絲都算不上，就是crud，這也是促使他出來的原因。

那麼，產生這個問題的原因是什麼呢？其實除了被炒起來的概念之外，也和微服務的概念有關係

主要從以下幾個方面跟大家分享：

微服務是什麼
為什麼要採用微服務
微服務架構
該如何學習微服務

關於微服務的態度，這是我見過最好的回答

架構模式有很多，微服務不是唯一的選擇也不是什麼銀彈。國內絕大多數中小公司引入微服務都是在盲目追新，也能看出做此種技術選型的工程師基礎架構素質的不足。

“你必須長的足夠高才能使用微服務”。微服務基礎設施，尤其是容器技術、自動化部署、自動化測試這些不完備，微服務形同虛設，不會帶來什麼質的提升。

微服務架構的關鍵不在於具體的實現，而在於如何合理地劃分服務邊界以及組織架構是否相匹配。不考慮研發團隊的規模和組成就盲目上微服務是不良的技術選型。

Spring Boot 是 Spring 全家桶的上層封裝，並不是什麼嶄新的技術，也不是什麼值得成為自己殺手鐧的技術。

Spring Cloud 中 Spring Cloud Netflix 的組件是經過生產環境驗證的，其他的則建議慎重選擇。

微服務是什麼

來看一下框架

微服務起源於 2005 年 Peter Rodgers 博士在雲端運算博覽會提出的微 Web 服務(Micro-Web-Service)，根本思想類似於 Unix 的管道設計理念。

2014 年，由 Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務架構風格是一種通過一套小型服務來開發單個應用的方法，每個服務運行在自己的進程中，並通過輕量級的機制進行通訊（HTTP API）。

關鍵的三點是：

small
automated
lightweight

對比 SOA，微服務可以看做是 SOA 的子集，是輕量級的 SOA，粒度更細的服務，獨立進程、數據分離，更注重敏捷、持續交付、DevOps 以及去中心化實踐。

其共同的架構原理：

單一職責
關注分離：控制與邏輯相分離
模塊化和分而治之

特點：

用服務進行組件化
圍繞業務能力進行組織
是產品而非項目
端點智能化和啞管道: 控制邏輯都在端點，管道僅僅是傳輸
全自動化部署
語言和數據的去中心化控制
面向失敗設計
漸進式設計

綜合來看，其優缺點如下：

優點： 模塊的強邊界；獨立部署；技術選型的多樣性。
缺點： 分佈式帶來編程複雜度，遠程調用的消耗；捨棄強一致性，實現最終一致性；操作複雜性要求有一個成熟的運維團隊或者運維基礎設施。

為什麼要採用微服務

是否選擇微服務取決於你要設計的系統的複雜度。微服務是用來把控複雜系統的，但是隨之而來的就是引入了微服務本身的複雜度。

需要解決包括自動化部署、監控、容錯處理、最終一致性等其他分佈式系統面臨的問題。即使已經有一些普遍使用的解決方案，但是仍然是有不小的成本的。

生產力和複雜度的關係如圖所示，可見系統越複雜，微服務帶來的收益越大。此外，無論是單體應用還是微服務，團隊的技能都需要能夠把控住。

馬丁·福勒的一個觀點是： 除非管理單體應用的成本已經太複雜了（太大導致很難修改和部署），否則都不要考慮微服務。

大部分應用都應該選擇單體架構，做好單體應用的模塊化而不是拆分成服務。

因此，系統一開始採用單體架構，做好模塊化，之後隨著系統變得越來越複雜、模塊/服務間的邊界越來越清晰，再重構為微服務架構是一個合理的架構演化路徑。

四個可以考慮上微服務的情況：

多人開發一個模塊/項目，提交代碼頻繁出現大量衝突。
模塊間嚴重耦合，互相依賴，每次變動需要牽扯多個團隊，單次上線需求太多，風險大。

主要業務和次要業務耦合，橫向擴展流程複雜。
熔斷降級全靠 if-else。

微服務的三個階段：

微服務 1.0： 僅使用註冊發現，基於 Spring Cloud 或者 Dubbo 進行開發。
微服務 2.0： 使用了熔斷、限流、降級等服務治理策略，並配備完整服務工具和平臺。
微服務 3.0： Service Mesh 將服務治理作為通用組件，下沉到平臺層實現，應用層僅僅關注業務邏輯，平臺層可以根據業務監控自動調度和參數調整，實現 AIOps 和智能調度。

微服務架構

先決條件

微服務的先決條件如下：

快速的環境提供能力： 依賴於雲計算、容器技術，快速交付環境。
基本的監控能力： 包括基礎的技術監控和業務監控。
快速的應用部署能力： 需要部署管道提供快速的部署能力。
Devops 文化： 需要具有良好的持續交付能力，包括全鏈路追蹤、快速環境提供和部署等，還需要快速的反應能力（對問題、故障的快速響應），開發和運維的協同工作。

此外，根據康威定律和逆康威定律（技術架構倒逼組織架構改進），組織架構也是一個很關鍵的因素。

對應於微服務架構，組織架構需要遵循以下原則：

一個微服務由一個團隊維護，團隊成員以三人為宜。
單個團隊的任務和發展是獨立的，不受其他因素影響。
團隊是功能齊全、全棧、自治的，扁平、自我管理。

。。。。。。。。。啊！！！

看到這裡，我覺得有些人已經看不下去了，因為真的是，自己公司的業務需求真的沒有達到這個級別，而且相關的人員和資源配置也達不到這個需求，但是，有很多人又會抱怨，確實是“面試造航母，工作擰螺絲”，但是，你有什麼辦法呢？大廠，體系架構相對來說比較完善，有自己的獨立的團隊，而小公司，就像我之前說的，可能就是單純的跟風，但是你有什麼辦法，大廠進不去，在小廠還不知道該怎麼學，因為大環境不允許，所以，小編整理了一部分學習書籍跟大家分享，有需要的，可以私信“資料”獲取，個人感覺這些書籍質量比較高，配合面試資料，你懂的。。。