軟件行業發展到現在，很多人都曾被大而全的產品折騰得苦不堪言。因此，近些年雲原生(Cloud Native)的概念也漸漸擴散開來。作爲雲原生基礎設施之一的"微服務"也備受矚目。那什麼是微服務，微服務又解決了哪些問題呢？今天小編以騰訊的開源微服務框架Tars爲例，跟大家聊聊微服務。
現實中的問題
在微服務以前，存在兩種情況：
- 單體架構：一個系統包含所有功能(大而全)；
- 多體架構：多個系統由多個不同團隊開發，開發標準(SDK、代碼風格、驗收標準等)各不相同。
單體架構的問題
- 單體架構中的系統代碼量過大，容易嚇跑新的開發人員;
- 超載IDE，代碼體量大，IDE運行加載慢，影響開發效率;
- 持續部署困難，牽一髮而動全身，無法進行快速迭代和頻繁部署;
- 擴展困難，不能通過簡單地增加實例的方法應對性能瓶頸，無法針對IO密集型、CPU密集型或內存密集型的業務進行資源分配;
- 擴展障礙，功能過多不可避免地由多人負責，人數越多，協調開發進度，更新產品越困難；
- 被原有技術棧綁架，單體架構強迫你必須在原有的技術棧上進行新功能開發，而與行業內新的語言和新的技術無緣。
![在這裏插入圖片描述]()
既然單體架構有問題，是不是我簡單的把一個系統拆分成多個系統就行了呢？那我們來看多體架構。
多體架構的問題
從開發的角度：
- 不同的產品，業務模型多樣化，開發語言不同；
- 不同產品之間的業務通信協議不統一，對接不同產品時的學習成本大;
- 容錯、容災、可擴展性等質量指標參差不齊，導致開發人員不能很好的聚焦於業務本身;
從維護角度：
- 不同業務之間的部署工具不同，運維人員花費大量時間在安裝調試系統環境上;
- 部署管理混亂，不同業務之間的配置文件互相依賴，需要運維人員完全理解產品所有業務邏輯;
- 產品週期長，轉測時需要協調各個組件的進度，開發團隊的整體運轉效率偏低;
監控能力薄弱，出問題之後需要用戶投訴才能發現問題。
全棧的問題
你可能會說，這都是大系統存在的問題，我一全棧的工程師，前端用Javascript後端用Nodejs，業務自己設計不和你們摻和在一起，總沒問題了吧。
但是你會直面老大的靈魂拷問：
- 你經過壓力測試了麼？
- 這個請求耗時太高了，不能上線；
- 能不能不要每次修改配置文件和緩存數據都重啓服務？
- 服務異常能及時告警麼？
- 需要有灰度邏輯啊，不能每次都在線上環境改啊；
- 線上出問題，你能及時定位到麼？
此時你的心情一定是這樣的：
微服務框架—Tars
如果你一直被上面這些問題困擾，那麼你可能就需要用到微服務了。
微服務是一種服務治理的思路，在業界沒有具體的定義，各家企業有自己的微服務標準，下面以騰訊開源的Tars爲例來介紹微服務。
Tars是什麼
Tars是將騰訊內部使用的微服務架構TAF（Total Application Framework）多年的實踐成果總結而成的開源項目。
有哪些成果
設計思想
Tars的目的：
讓開發人員更加聚焦於業務邏輯本身;
讓運維人員只需關注日常服務部署、發佈、配置、監控、調度管理等操作。
從上圖中可以看出，微服務框架將容災、負載、監控、部署、協議等通用功能抽離出來開放給開發人員使用, 既能讓開發人員更聚焦於業務本身，又能讓運維人員從業務邏輯中解脫出來。
通常好的微服務，有以下特點：
- 可擴展好：業務之間用接口通信
- 易用性好：公共組件和通信框架省去很多代碼，支持RPC調用
- 支持多語言：讓開發人員有更大的發揮空間
- 性能高：異步通信，資源按需分配
- 分佈式部署：開發人員不用關心負載均衡、備份容災等問題
整體架構
Web管理系統： 在Web上可以看到服務運行的各種實時數據情況，以及對服務進行發佈、啓停、部署等操作；
Registry（路由+管理服務）： 提供服務節點的地址查詢、發佈、啓停、管理等操作，以及對服務上報心跳的管理，通過它實現服務的註冊與發現；
Patch（發佈管理）： 提供服務的發佈功能；
Config（配置中心）： 提供服務配置文件的統一管理功能；
Log（遠程日誌）： 提供服務打日誌到遠程的功能；
Stat（調用統計）： 統計業務服務上報的各種調用信息，比如總流量、平均耗時、超時率等，以便對服務出現異常時進行告警；
Property（業務屬性）： 統計業務自定義上報的屬性信息，比如內存使用大小、隊列大小、cache命中率等，以便對服務出現異常時進行告警；
Notify（異常信息）： 統計業務上報的各種異常信息，比如服務狀態變跟信息、訪問db失敗信息等，以便對服務出現異常時進行告警；
服務交互流程圖
框架服務在整個系統中運行時，服務之間的交互分：
- 業務服務之間的交互;
- 業務服務與框架基礎服務之間的交互。
服務發佈流程： 在Web系統上傳server的發佈包到patch，上傳成功後，在web上提交發布server請求，由registry服務傳達到node，然後node拉取server的發佈包到本地，拉起server服務。
管理命令流程： Web系統上的可以提交管理server服務命令請求，由registry服務傳達到node服務，然後由node向server發送管理命令。
心跳上報流程： server服務運行後，會定期上報心跳到node，node然後把服務心跳信息上報到registry服務，由registry進行統一管理。
信息上報流程： server服務運行後，會定期上報統計信息到stat，打印遠程日誌到log，定期上報屬性信息到property、上報異常信息到notify、從config拉取服務配置信息。
Client訪問Server流程： client可以通過server的對象名Obj間接訪問server，Client會從registry上拉取server的路由信息（如ip、port信息），然後根據具體的業務特性（同步或者異步，tcp或者udp方式）訪問server(當然client也可以通過ip/port直接訪問server)。
微服務不是銀彈
雖然微服務有諸多好處，但也不是萬能的。
很多企業在實踐中，也發現了以下問題：
- 軟件架構本身受限於企業的組織架構；(即康威定律，如上圖，公司的組織架構就決定了公司的軟件架構)
- 把舊的業務遷移到微服務上工作量並不小，而且還有很多坑要踩;
- 通常小型企業相比於自己搭建微服務，並不會比用第三方服務更划算;
- 使用微服務必須遵循微服務的規範，並不是所有的業務都適合。(比如：所有請求必須是異步的，要在業務層面考慮到有可能相同客戶端的多個請求可能落在不同服務器的情況，最好讀寫分離等)
如果您對微服務感興趣，請掃描下方二維碼，關注“麻辣軟硬件”公衆號，小編後續將爲您介紹Tars的安裝和使用。
