迴歸架構本質，重新理解微服務
第一部分：微服務的誕生、演變以及應用策略
記者：近幾年來，微服務架構設計方式被提出並在越來越多的企業中得以實踐和落地，但對於剛開始接觸微服務的人來說，還是不知道要從哪些方面開始瞭解。您能否結合軟體架構的發展歷史，聊聊微服務的發展與特徵。
樑鑫：微服務本質上是一種架構的風格，如果要了解微服務，我認為需要先了解整個架構的發展脈絡。
軟體架構，總是在不斷的演進中。如果把時間退回到二十年前，當時企業級領域研發主要推崇的還是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-task
記者：微服務任務排程平臺（SIA-TASK）適用於哪些場景?
樑鑫：SIA-TASK是基於HTTP協議的進行遠端排程的，實際業務中高併發的排程處理支援肯定是不夠理想的。如果業務是高併發的、每秒鐘需要喚醒幾千幾萬個任務的場景就不太適合使用SIA-TASK。除此之外，其他所有場景幾乎都可使用SIA-TASK。