專訪宜信梁鑫：迴歸架構本質，從新理解微服務

本期專訪宜信開發平臺（SIA）負責人梁鑫，與你們一塊兒聊聊微服務架構及其在企業落地應用的策略。

第一部分：微服務的誕生、演變以及應用策略

記者：近幾年來，微服務架構設計方式被提出並在愈來愈多的企業中得以實踐和落地，但對於剛開始接觸微服務的人來講，仍是不知道要從哪些方面開始瞭解。您可否結合軟件架構的發展歷史，聊聊微服務的發展與特徵。

梁鑫：微服務本質上是一種架構的風格，若是要了解微服務，我認爲須要先了解整個架構的發展脈絡。

軟件架構，老是在不斷的演進中。若是把時間退回到二十年前，當時企業級領域研發主要推崇的仍是C/S模式，PB、Delphi這樣的開發軟件是企業應用開發的主流。

隨着時間的推移，咱們發現標準化的客戶端存在一些弊病，好比我有一千個終端，升級版本須要每一臺終端都升級，這是很是麻煩的。而後，企業應用研發開始向互聯網學習，把瀏覽器做爲客戶端來使用，就能夠避免這個問題。所以，基於瀏覽器的B/S架構開始漸漸流行起來。

剛開始的時候是ASP，以後又出現了JSP，由於Java的預編譯模式，讓性能有了很是大的提高，隨後基於Java語言的J2EE架構就變得愈來愈流行。至此，架構經歷了從傳統的C/S模式到B/S模式的轉變。

B/S架構初期基本都是單體架構，各個系統比較獨立，他們之間每每不須要進行交互，即便存在一些交互，也大可能是數據層面的。那個階段ETL工具發展得很快，就是爲了解決這樣的數據孤島問題。

隨着企業應用愈來愈多，系統之間相互的關係也愈來愈密切，系統之間實時交互訪問的需求也愈來愈多。這個時候工程師們發現，無論是什麼語言開發的軟件，基本都支持一種叫作XML的語言，因而提出一種實時交互的技術解決方案：經過XML語言來進行企業應用系統之間的遠程調用。由此，SOA的概念被提了出來，WebService開始流行。

當第二波互聯網浪潮來臨後，不少公司爲了適應更加靈活的業務發展，用基於HTTP協議和Restful的架構風格替代了原先笨重的WebService，簡潔清晰的JSON替代了XML。同時SOA架構中經常採用服務總線技術，無疑是給系統架構增長了一個異常麻煩的瓶頸。若是使用註冊和發現的機制，讓服務進程之間直接進行調用，更適合企業應用的發展。這就是微服務架構從技術方面來講的歷史脈絡。

在《微服務設計》中界定微服務有兩個基本原則：鬆耦合&高內聚。即「把因相同因素變化的事情彙集在一塊兒，把因不一樣因素變化的事情區隔開來。」至於微服務大小的劃分並無統一的標準，通俗地說，就是你以爲它的大小差很少，同時符合「鬆耦合&高內聚」的原則就能夠。

微服務有不少的好處，大體列舉一些。

• 異構：微服務能夠幫助咱們輕鬆採用不一樣的技術，而且理解這些新技術的好處。嘗試新技術一般伴隨着風險，但若是把服務切得很小了，總會存在一些點讓你能夠選擇一個風險最小的服務採用新技術，並下降風險。
• 彈性：很明顯，微服務能夠很好地處理服務不可用和功能降級的問題，由於它能夠造成不少個節點。
• 隔離：微服務架構將系統分解爲獨立運行單元，給系統帶來更好的隔離性，獨立的微服務在發生異常時更容易定位和隔離問題，隔離性也是服務擴展性的基礎。
• 擴展：龐大的單體服務只能做爲一個總體進行擴展，即便系統中只有一小部分模塊存在性能問題，也須要對整個系統進行擴展。而微服務架構能夠根據性能須要對不一樣的模塊進行水平擴展。
• 部署簡單：在微服務架構中，各個服務的部署是獨立的，這樣就能夠更快地對特定部分的代碼進行部署。服務出現問題也更容易快速回滾，同時敏捷的交付和部署帶來了更好的業務需求響應體驗。
• 靈活：在微服務架構中，系統會開放不少接口供外部使用，當狀況發生改變時，可使用不一樣的方式構建應用。把單體應用分解成多個微服務，能夠達到可複用、可組合的目的。

記者：據悉，您以前發表過一篇文章「公司爲何須要創建一套統一的開發框架？」，您認爲公司創建統一開發框架是爲了解決什麼問題？

梁鑫：這是一個仁者見仁智者見智的問題，每一個人的出發點都不同，有的人可能主張須要統一，有的人則可能排斥統一，結合個人經歷和實踐來看，我認爲公司是須要創建統一開發框架的。

近十年，互聯網的發展顛覆了不少傳統行業，不少新興公司如雨後春筍般的冒了出來，它們的業務增加很是快，公司規模也愈來愈大。這得益於中國經濟的高速增加和互聯網的快速發展。但這種高速的發展過程當中伴隨而來的是不可忽視的弊端：

• 弊端一：自我繁衍

在公司快速的發展過程當中，每每會出現這樣一個鏈條。新增一塊業務 —> 招聘一位高級技術人員 —> 圍繞這位同事組建一支技術團隊 —> 該業務基本由這隻團隊負責，而後就造成了一個閉環。當須要跟其餘業務進行交互時，常常是技術負責人之間自行決定。這就造成了自我繁衍的狀態。

• 弊端二：管控壁壘

隨着業務規模的快速發展，這個團隊很快造成了一個部門，團隊決策者一般會從自身利益考量，但願儘可能減小對外部門的依賴，不管是技術選型、規範創建、組件選取、運行環境都可以自行掌控。

• 弊端三：斷崖效應

當這樣的技術氛圍一旦造成，單個員工對單個項目的影響就會變的很是巨大。一個產品常常會由於一兩個核心員工的離職難覺得繼，最後不得不從新開發新的產品。

• 弊端四：資源浪費

當每一個團隊都在試圖構建本身完整的研發流程時。中間的技術研究、產品研發、運維管理就會出現很是多的資源浪費。

• 弊端五：難以考覈

怎麼衡量一個川菜廚師和一個魯菜廚師誰更優秀？當每一個團隊都是一個閉環，採用不一樣技術棧、不一樣的技術組件、不一樣的維護方式和規範時，已經沒法從產出效率來判斷一個團隊的績效，KPI 指標也就很是難以設立。

創建一套公司級的統一的開發平臺能夠有效解決上述問題。從技術層面來說，若是能夠造成公司級別的統一開發平臺，會在實際的生產過程當中帶來很是大的收益。

• 首先，避免了重複性技術研究，節約了人力成本。在項目組之下構建一個基礎的開發架構平臺，把技術共性問題提煉出來，交給一個專門團隊負責處理，讓項目組把精力投入到業務中。
• 其次，標準化了技術規範，提高了產品項目質量。作工程要千人一面，而不要千人千面。採用統一的開發平臺後，在技術棧、技術組件、技術實現方案，甚至在代碼規範上，就能造成標準化的技術輸出模式，標準化帶來的效果不只僅是開發效率的快速提高，還有產品質量的大幅提高。
• 再次，能夠進行技術沉澱，提高公司總體的技術能力，避免陷入一我的的能力決定一個項目。技術的進步來源於不斷的技術積累和沉澱，創建公司級別的統一開發框架（平臺），項目團隊基於該平臺進行自身項目的研發，再也不須要關注於底層技術實現，只須要關注業務便可。並且，專一於平臺的同事爲了更好地知足項目組的技術需求，對平臺進行不斷的改進，從而達到技術積累和沉澱的目標。
• 最後，能夠對研發的投入和產出進行衡量，對研發團隊進行有效管理和考覈。當基於同一開發平臺的標準化技術規範創建起來後，對業務功能的代碼實現就能夠進行相對有效的評估和考量，能夠避免由於技術實現差別而出現的種種問題。這對KPI的制定和考覈是一個巨大的幫助。

我從前年提出這樣的一個思想，經過一年多的努力，已經在公司有了必定的成果。咱們的統一開發平臺定位於技術層面，其主要目的是爲統一公司內相關產品研發和項目實施使用的技術架構和開發工具，有效提升統一技術支持力度，造成持續的技術積累手段，提高技術人員的利用率並下降對人員的依賴性，最終提高軟件的規模化、流水線式的生產能力。

記者：最近「Spring Boot」、「Spring Cloud」等詞總被說起，這些新的框架集合方案與傳統的微服務框架相比有哪些優點？結合您的經驗來看，您認爲微服務將來的發展走向多是什麼？

梁鑫：我是公司內部較早研究Spring Cloud 技術棧的人，也是Spring Cloud中國社區的成員。Spring Cloud是在2017年一躍成爲最流行的微服務開發框架。可是，這裏有一個須要辯證看待的問題。「不是說使用了Spring Cloud框架就實現了微服務架構，具有了微服務架構的優點」，正確的理解應該是「使用Spring Cloud框架開發微服務架構系統，使系統具有微服務架構的優點。」

Spring Cloud之因此能從其餘框架中脫穎而出成爲最火的框架，得益於其自己體系的完整性。這一點經過下圖Spring Cloud、Dubbo和ServiceComb的對比能夠比較直觀地瞭解到。

另外，Spring在中國有普遍的羣衆基礎，我也比較推崇這種「約定大於配置」的研發思想，不須要徹底依賴標準化的東西。

我不敢妄談微服務架構的將來走向。立足當下，我認爲目前Spring Cloud+Docker容器化的技術是用於微服務架構的一個比較好的選擇。我比較承認一個頗有趣的說法是「基因架構」，意思是：架構從誕生之初就是爲了改變的，因此你的架構越容易改變就越好。我以爲架構的將來會向這條路發展。

咱們的統一開發平臺的建設就是基於Spring Cloud技術棧。

記者：今年在軟件研發行業比較熱門的話題是「中臺」，在架構層面也有人提出來要作微服務中臺，對此您怎麼看？

梁鑫：去年一個綜藝節目帶火了一句話，「盤它」。節目裏有一句 「乾乾巴巴的，麻麻賴賴的，一點都不圓潤，盤他！」。 後來講到什麼就盤什麼，也無論是什麼東西，能不能握在手中，反正盤就是了。聽起來是否是特別有魔性，而後就有了「萬物皆可盤」這個段子。這自己其實只是一種調侃的講法，也並不會真的有人看到什麼就盤什麼。有意思的是任何事情均可以再認真往深處想想，你會不會也犯一些看似荒唐的錯誤呢？

今年技術圈最火的一個名詞就是「中臺」，套用到這兒就變成了「萬物皆可中臺」，一個名詞處處套，我認爲不少公司應該避免盲目跟風，讓「中臺」成爲名詞陷阱。

面對一個新的技術或趨勢，咱們要先了解其來源和根本。中臺的來源須要回溯到阿里。2015年阿里巴巴集團啓動了中臺戰略，目標是要構建符合互聯網大數據時代的，具備創新性、靈活性的‘大中臺、小前臺’的機制，即做爲前臺的一線業務會更敏捷、更快速地適用瞬息萬變的市場，而中臺將集合整個集團的運營數據能力、產品技術能力，對各前臺業務造成強有力的支撐.

那阿里集團爲何要創建一個‘大中臺、小前臺’的架構呢？《企業IT架構轉型之道——阿里巴巴中臺戰略思考與架構實戰》一書對此有詳細介紹。從阿里共享業務事業部的發展史提及，起初，阿里只有一個淘寶事業部，後來成立了天貓事業部，此時淘寶的技術團隊同時支撐着這兩個事業部。當時的淘寶和天貓的電商系統像咱們不少大型企業的同樣是分爲兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。由於上述緣由，阿里集團又成立了共享業務事業部，其成員主要來自以前的淘寶技術團隊，同時將兩套電商業務作了梳理和沉澱，將兩個平臺中公共的、通用的業務功能沉澱到共享事業部，避免重複建設和維護。

做爲一個擁有10多年編程經驗的老兵，我常常思考的一個問題就是系統發展的規律，透過其形領會其意，回顧架構的發展，我認爲能夠總結出一點：「快」。固然這個快是有前提的，好比正確率、資源限制，要在穩定、儘可能減小資源消耗的狀況下求快。

「快」能夠再次分解，從開發的角度來看，編寫代碼要快、開發要快、功能測試要快、環境部署要快、服務啓停要快；從生產的角度來看，程序運行的速度要快、高併發之下仍是要快等。

微服務架構之因此流行，由於把服務拆小了，能夠高度複用，不用常常編寫和修改代碼，節省了很是多的時間；容器化技術之因此流行，由於容器化技術可使得生產環境和測試環境一致，節省了大量的環境部署時間、減小了出錯的可能性，還能夠隨意增長容器節點，加強業務處理能力，保證高併發下的快速響應。分佈式架構也是如此，微服務架構其實就是分佈式架構的一種演化。萬變不離其宗，都是追求「快」。

回到「中臺」這個話題，建設中臺的目標是避免重複建設和維護，快速響應需求。後臺和平臺的系統比較穩定，通常不輕易發生變化，並且從穩定性考慮，應該儘可能減小後臺和平臺系統更新的次數，前端系統由於要適用用戶的需求而不斷變化，這樣前臺和後臺在對接時就產生了一個求變一個求不變的矛盾，這時咱們但願在二者之間創建一箇中間平臺，把前端後臺可重複利用的東西集中到這個中間平臺來，從新封裝組合對外提供服務，這是符合「快」的思想的。

這是中臺的來源和根本，企業在建設中臺以前，必定要先了解這些，看所要建設的中臺是否符合「避免重複建設和維護」的思想，是否符合「快」的原則。

第二部分：微服務在業務中的應用須要解決的關鍵問題

記者：宜信在今年開源了微服務任務調度平臺SIA-TASK，這個平臺在宜信技術團隊內部有普遍的應用，開源後也獲得了不少開發者的支持。您可否介紹一下這個平臺的設計思路以及核心功能？（設計開發這個平臺想要解決什麼問題）

梁鑫：前面談到中臺，其實我認爲「中臺」只是一個名稱而已，只要符合「避免重複建設和維護」和「快」兩個原則，叫什麼均可以，好比咱們的微服務調度平臺SIA-TASK，就是一個很像中臺的系統。

介紹SIA-TASK的設計思想以前，我先介紹一下它的背景。不管是互聯網應用或者企業級應用，都充斥着大量的批處理任務。經常須要一些任務調度系統幫助開發者解決問題。隨着微服務化架構的逐步演進，單體架構逐漸演變爲分佈式、微服務架構。不少原先的任務調度平臺已經不能知足業務系統的需求，因而出現了一些基於分佈式的任務調度平臺。這些平臺各有其特色，也各有不足之處，好比不支持任務編排、與業務高耦合、不支持跨平臺等問題，不符合新一代微服務架構的需求，所以咱們開發了微服務任務調度平臺（SIA-TASK）。

SIA-TASK 使用 SpringBoot 體系做爲架構選型，基於Quartz及Zookeeper進行二次開發，支持相應的特性功能，SIA-TASK 的邏輯架構圖以下圖所示：

SIA-TASK是任務調度平臺的一站式解決方案，契合當前微服務架構模式，具備跨平臺，可編排，高可用，無侵入，一致性，異步並行，動態擴展，實時監控等特色。

瞭解任務調度平臺，須要先了解任務調度。任務大體分爲三種，按期執行的任務；隔固定時間執行但不可併發的任務；每隔固定時間執行的可是能夠併發的任務。任務之間還可能存在一些次序關係，好比：串行、並行、分支等。

當咱們進行任務調度的時候，經常會發生如下的一些問題。

• 遺忘，一個項目有跑批任務，項目下線後跑批流程還在繼續，直到產生的日誌把磁盤空間佔滿了才發現；
• 單點，某個項目的跑批流程一直單點，機器故障後，流程中止運行；
• 依賴，某個項目的跑批流程A和B有依賴關係，只能設置兩個任務的時間錯開，若是發生A延時，須要手工處理出錯數據。

咱們在設計SIA-TASK的時候，將平臺和項目組運行割裂開來。SIA-TASK包括五大模塊，任務執行器，即真正業務邏輯須要跑批的業務，屬於項目組，項目組在啓動的時候會把執行的任務暴露成一個服務，這個服務註冊到任務註冊中心來；任務註冊中心拿到一個任務，並將它存儲到持久存儲的數據庫裏，同時進行編排，編排成有依賴關係的任務；最後任務調度中心拿到任務編排中內心已經編排好的須要執行的任務，進行遠程調用。

在整個過程當中，任務調度、編排、執行與項目組是分開的，項目組只須要關心任務調度的業務邏輯代碼，剩下的都在SIA-TASK平臺執行，至關於把每一個項目任務都原子化了，都變成了一個個微服務。

只把業務邏輯留在項目組，調度、編排、執行歸類到平臺中，全部須要代碼處理的東西都經過配置化的方式實現，也符合中臺「避免重複建設的維護」的思想。

SIA-TASK目前已經開源，具體的設計思想和功能以及部署操做能夠在GitHub查看，地址： https://github.com/siaorg/sia...

記者：微服務任務調度平臺（SIA-TASK）適用於哪些場景?

梁鑫：SIA-TASK是基於HTTP協議的進行遠程調度的，實際業務中高併發的調度處理支持確定是不夠理想的。若是業務是高併發的、每秒鐘須要喚醒幾千幾萬個任務的場景就不太適合使用SIA-TASK。除此以外，其餘全部場景幾乎均可使用SIA-TASK。