回歸架構本質，重新理解微服務

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

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

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

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

隨著時間的推移，我們發現標準化的客戶端存在一些弊病，比如我有一千個終端，升級版本需要每一臺終端都升級，這是非常麻煩的。然后，企業應用研發開始向互聯網學習，把瀏覽器作為客戶端來使用，就可以避免這個問題。因此，基于瀏覽器的B/S架構開始漸漸流行起來。

剛開始的時候是ASP，之后又出現了JSP，因為Ja.va的預編譯模式，讓性能有了非常大的提升，隨后基于Ja.va語言的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年一躍成為最流行的微服務開發框架。但是，這里有一個需要辯證看待的問題?！安皇钦f使用了Spring Cloud框架就實現了微服務架構，具備了微服務架構的優勢”，正確的理解應該是“使用Spring Cloud框架開發微服務架構系統，使系統具備微服務架構的優勢?！?/p>

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-task

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

梁鑫：SIA-TASK是基于HTTP協議的進行遠程調度的，實際業務中高并發的調度處理支持肯定是不夠理想的。如果業務是高并發的、每秒鐘需要喚醒幾千幾萬個任務的場景就不太適合使用SIA-TASK。除此之外，其他所有場景幾乎都可使用SIA-TASK。