專訪宜信梁鑫：回歸架構(gòu)本質(zhì)，重新理解微服務(wù)

本期專訪宜信開發(fā)平臺（SIA）負(fù)責(zé)人梁鑫，與大家一起聊聊微服務(wù)架構(gòu)及其在企業(yè)落地應(yīng)用的策略。

第一部分：微服務(wù)的誕生、演變以及應(yīng)用策略

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

梁鑫：微服務(wù)本質(zhì)上是一種架構(gòu)的風(fēng)格，如果要了解微服務(wù)，我認(rèn)為需要先了解整個(gè)架構(gòu)的發(fā)展脈絡(luò)。

軟件架構(gòu)，總是在不斷的演進(jìn)中。如果把時(shí)間退回到二十年前，當(dāng)時(shí)企業(yè)級領(lǐng)域研發(fā)主要推崇的還是C/S模式，PB、Delphi這樣的開發(fā)軟件是企業(yè)應(yīng)用開發(fā)的主流。

隨著時(shí)間的推移，我們發(fā)現(xiàn)標(biāo)準(zhǔn)化的客戶端存在一些弊病，比如我有一千個(gè)終端，升級版本需要每一臺終端都升級，這是非常麻煩的。然后，企業(yè)應(yīng)用研發(fā)開始向互聯(lián)網(wǎng)學(xué)習(xí)，把瀏覽器作為客戶端來使用，就可以避免這個(gè)問題。因此，基于瀏覽器的B/S架構(gòu)開始漸漸流行起來。

剛開始的時(shí)候是ASP，之后又出現(xiàn)了JSP，因?yàn)镴ava的預(yù)編譯模式，讓性能有了非常大的提升，隨后基于Java語言的J2EE架構(gòu)就變得越來越流行。至此，架構(gòu)經(jīng)歷了從傳統(tǒng)的C/S模式到B/S模式的轉(zhuǎn)變。

B/S架構(gòu)初期基本都是單體架構(gòu)，各個(gè)系統(tǒng)比較獨(dú)立，他們之間往往不需要進(jìn)行交互，即使存在一些交互，也大多是數(shù)據(jù)層面的。那個(gè)階段ETL工具發(fā)展得很快，就是為了解決這樣的數(shù)據(jù)孤島問題。

隨著企業(yè)應(yīng)用越來越多，系統(tǒng)之間相互的關(guān)系也越來越密切，系統(tǒng)之間實(shí)時(shí)交互訪問的需求也越來越多。這個(gè)時(shí)候工程師們發(fā)現(xiàn)，不管是什么語言開發(fā)的軟件，基本都支持一種叫做XML的語言，于是提出一種實(shí)時(shí)交互的技術(shù)解決方案：通過XML語言來進(jìn)行企業(yè)應(yīng)用系統(tǒng)之間的遠(yuǎn)程調(diào)用。由此，SOA的概念被提了出來，WebService開始流行。

當(dāng)?shù)诙ɑヂ?lián)網(wǎng)浪潮來臨后，很多公司為了適應(yīng)更加靈活的業(yè)務(wù)發(fā)展，用基于HTTP協(xié)議和Restful的架構(gòu)風(fēng)格替代了原先笨重的WebService，簡潔清晰的JSON替代了XML。同時(shí)SOA架構(gòu)中常常采用服務(wù)總線技術(shù)，無疑是給系統(tǒng)架構(gòu)增加了一個(gè)異常麻煩的瓶頸。如果使用注冊和發(fā)現(xiàn)的機(jī)制，讓服務(wù)進(jìn)程之間直接進(jìn)行調(diào)用，更適合企業(yè)應(yīng)用的發(fā)展。這就是微服務(wù)架構(gòu)從技術(shù)方面來說的歷史脈絡(luò)。

在《微服務(wù)設(shè)計(jì)》中界定微服務(wù)有兩個(gè)基本原則：松耦合&高內(nèi)聚。即“把因相同因素變化的事情聚集在一起，把因不同因素變化的事情區(qū)隔開來。”至于微服務(wù)大小的劃分并沒有統(tǒng)一的標(biāo)準(zhǔn)，通俗地說，就是你覺得它的大小差不多，同時(shí)符合“松耦合&高內(nèi)聚”的原則就可以。

微服務(wù)有很多的好處，大致列舉一些。

異構(gòu)：微服務(wù)可以幫助我們輕松采用不同的技術(shù)，并且理解這些新技術(shù)的好處。嘗試新技術(shù)通常伴隨著風(fēng)險(xiǎn)，但如果把服務(wù)切得很小了，總會存在一些點(diǎn)讓你可以選擇一個(gè)風(fēng)險(xiǎn)最小的服務(wù)采用新技術(shù)，并降低風(fēng)險(xiǎn)。

彈性：很明顯，微服務(wù)可以很好地處理服務(wù)不可用和功能降級的問題，因?yàn)樗梢孕纬珊芏鄠€(gè)節(jié)點(diǎn)。

隔離：微服務(wù)架構(gòu)將系統(tǒng)分解為獨(dú)立運(yùn)行單元，給系統(tǒng)帶來更好的隔離性，獨(dú)立的微服務(wù)在發(fā)生異常時(shí)更容易定位和隔離問題，隔離性也是服務(wù)擴(kuò)展性的基礎(chǔ)。

擴(kuò)展：龐大的單體服務(wù)只能作為一個(gè)整體進(jìn)行擴(kuò)展，即使系統(tǒng)中只有一小部分模塊存在性能問題，也需要對整個(gè)系統(tǒng)進(jìn)行擴(kuò)展。而微服務(wù)架構(gòu)可以根據(jù)性能需要對不同的模塊進(jìn)行水平擴(kuò)展。

部署簡單：在微服務(wù)架構(gòu)中，各個(gè)服務(wù)的部署是獨(dú)立的，這樣就可以更快地對特定部分的代碼進(jìn)行部署。服務(wù)出現(xiàn)問題也更容易快速回滾，同時(shí)敏捷的交付和部署帶來了更好的業(yè)務(wù)需求響應(yīng)體驗(yàn)。

靈活：在微服務(wù)架構(gòu)中，系統(tǒng)會開放很多接口供外部使用，當(dāng)情況發(fā)生改變時(shí)，可以使用不同的方式構(gòu)建應(yīng)用。把單體應(yīng)用分解成多個(gè)微服務(wù)，可以達(dá)到可復(fù)用、可組合的目的。

記者：據(jù)悉，您之前發(fā)表過一篇文章“公司為什么需要建立一套統(tǒng)一的開發(fā)框架？”，您認(rèn)為公司建立統(tǒng)一開發(fā)框架是為了解決什么問題？

梁鑫：這是一個(gè)仁者見仁智者見智的問題，每個(gè)人的出發(fā)點(diǎn)都不一樣，有的人可能主張需要統(tǒng)一，有的人則可能排斥統(tǒng)一，結(jié)合我的經(jīng)歷和實(shí)踐來看，我認(rèn)為公司是需要建立統(tǒng)一開發(fā)框架的。

近十年，互聯(lián)網(wǎng)的發(fā)展顛覆了很多傳統(tǒng)行業(yè)，很多新興公司如雨后春筍般的冒了出來，它們的業(yè)務(wù)增長非常快，公司規(guī)模也越來越大。這得益于中國經(jīng)濟(jì)的高速增長和互聯(lián)網(wǎng)的快速發(fā)展。但這種高速的發(fā)展過程中伴隨而來的是不可忽視的弊端：

弊端一：自我繁衍

在公司快速的發(fā)展過程中，往往會出現(xiàn)這樣一個(gè)鏈條。新增一塊業(yè)務(wù) —> 招聘一位高級技術(shù)人員 —> 圍繞這位同事組建一支技術(shù)團(tuán)隊(duì) —> 該業(yè)務(wù)基本由這只團(tuán)隊(duì)負(fù)責(zé)，然后就形成了一個(gè)閉環(huán)。當(dāng)需要跟其他業(yè)務(wù)進(jìn)行交互時(shí)，經(jīng)常是技術(shù)負(fù)責(zé)人之間自行決定。這就形成了自我繁衍的狀態(tài)。

弊端二：管控壁壘

隨著業(yè)務(wù)規(guī)模的快速發(fā)展，這個(gè)團(tuán)隊(duì)很快形成了一個(gè)部門，團(tuán)隊(duì)決策者通常會從自身利益考量，希望盡量減少對外部門的依賴，無論是技術(shù)選型、規(guī)范建立、組件選取、運(yùn)行環(huán)境都能夠自行掌控。

弊端三：斷崖效應(yīng)

當(dāng)這樣的技術(shù)氛圍一旦形成，單個(gè)員工對單個(gè)項(xiàng)目的影響就會變的非常巨大。一個(gè)產(chǎn)品經(jīng)常會因?yàn)橐粌蓚€(gè)核心員工的離職難以為繼，最后不得不重新開發(fā)新的產(chǎn)品。

弊端四：資源浪費(fèi)

當(dāng)每個(gè)團(tuán)隊(duì)都在試圖構(gòu)建自己完整的研發(fā)流程時(shí)。中間的技術(shù)研究、產(chǎn)品研發(fā)、運(yùn)維管理就會出現(xiàn)非常多的資源浪費(fèi)。

弊端五：難以考核

怎么衡量一個(gè)川菜廚師和一個(gè)魯菜廚師誰更優(yōu)秀？當(dāng)每個(gè)團(tuán)隊(duì)都是一個(gè)閉環(huán)，采用不同技術(shù)棧、不同的技術(shù)組件、不同的維護(hù)方式和規(guī)范時(shí)，已經(jīng)無法從產(chǎn)出效率來判斷一個(gè)團(tuán)隊(duì)的績效，KPI 指標(biāo)也就非常難以設(shè)立。

建立一套公司級的統(tǒng)一的開發(fā)平臺可以有效解決上述問題。從技術(shù)層面來講，如果可以形成公司級別的統(tǒng)一開發(fā)平臺，會在實(shí)際的生產(chǎn)過程中帶來非常大的收益。

首先，避免了重復(fù)性技術(shù)研究，節(jié)約了人力成本。在項(xiàng)目組之下構(gòu)建一個(gè)基礎(chǔ)的開發(fā)架構(gòu)平臺，把技術(shù)共性問題提煉出來，交給一個(gè)專門團(tuán)隊(duì)負(fù)責(zé)處理，讓項(xiàng)目組把精力投入到業(yè)務(wù)中。

其次，標(biāo)準(zhǔn)化了技術(shù)規(guī)范，提升了產(chǎn)品項(xiàng)目質(zhì)量。做工程要千人一面，而不要千人千面。采用統(tǒng)一的開發(fā)平臺后，在技術(shù)棧、技術(shù)組件、技術(shù)實(shí)現(xiàn)方案，甚至在代碼規(guī)范上，就能形成標(biāo)準(zhǔn)化的技術(shù)輸出模式，標(biāo)準(zhǔn)化帶來的效果不僅僅是開發(fā)效率的快速提升，還有產(chǎn)品質(zhì)量的大幅提升。

再次，可以進(jìn)行技術(shù)沉淀，提升公司整體的技術(shù)能力，避免陷入一個(gè)人的能力決定一個(gè)項(xiàng)目。技術(shù)的進(jìn)步來源于不斷的技術(shù)積累和沉淀，建立公司級別的統(tǒng)一開發(fā)框架（平臺），項(xiàng)目團(tuán)隊(duì)基于該平臺進(jìn)行自身項(xiàng)目的研發(fā)，不再需要關(guān)注于底層技術(shù)實(shí)現(xiàn)，只需要關(guān)注業(yè)務(wù)即可。而且，專注于平臺的同事為了更好地滿足項(xiàng)目組的技術(shù)需求，對平臺進(jìn)行不斷的改進(jìn)，從而達(dá)到技術(shù)積累和沉淀的目標(biāo)。

最后，可以對研發(fā)的投入和產(chǎn)出進(jìn)行衡量，對研發(fā)團(tuán)隊(duì)進(jìn)行有效管理和考核。當(dāng)基于同一開發(fā)平臺的標(biāo)準(zhǔn)化技術(shù)規(guī)范建立起來后，對業(yè)務(wù)功能的代碼實(shí)現(xiàn)就可以進(jìn)行相對有效的評估和考量，可以避免因?yàn)榧夹g(shù)實(shí)現(xiàn)差異而出現(xiàn)的種種問題。這對KPI的制定和考核是一個(gè)巨大的幫助。

我從前年提出這樣的一個(gè)思想，通過一年多的努力，已經(jīng)在公司有了一定的成果。我們的統(tǒng)一開發(fā)平臺定位于技術(shù)層面，其主要目的是為統(tǒng)一公司內(nèi)相關(guān)產(chǎn)品研發(fā)和項(xiàng)目實(shí)施使用的技術(shù)架構(gòu)和開發(fā)工具，有效提高統(tǒng)一技術(shù)支持力度，形成持續(xù)的技術(shù)積累手段，提升技術(shù)人員的利用率并降低對人員的依賴性，最終提升軟件的規(guī)模化、流水線式的生產(chǎn)能力。

記者：最近“Spring Boot”、“Spring Cloud”等詞總被提及，這些新的框架集合方案與傳統(tǒng)的微服務(wù)框架相比有哪些優(yōu)勢？結(jié)合您的經(jīng)驗(yàn)來看，您認(rèn)為微服務(wù)未來的發(fā)展走向可能是什么？

梁鑫：我是公司內(nèi)部較早研究Spring Cloud 技術(shù)棧的人，也是Spring Cloud中國社區(qū)的成員。Spring Cloud是在2017年一躍成為最流行的微服務(wù)開發(fā)框架。但是，這里有一個(gè)需要辯證看待的問題。“不是說使用了Spring Cloud框架就實(shí)現(xiàn)了微服務(wù)架構(gòu)，具備了微服務(wù)架構(gòu)的優(yōu)勢”，正確的理解應(yīng)該是“使用Spring Cloud框架開發(fā)微服務(wù)架構(gòu)系統(tǒng)，使系統(tǒng)具備微服務(wù)架構(gòu)的優(yōu)勢。”

Spring Cloud之所以能從其他框架中脫穎而出成為最火的框架，得益于其本身體系的完整性。這一點(diǎn)通過下圖Spring Cloud、Dubbo和ServiceComb的對比可以比較直觀地了解到。

另外，Spring在中國有廣泛的群眾基礎(chǔ)，我也比較推崇這種“約定大于配置”的研發(fā)思想，不需要完全依賴標(biāo)準(zhǔn)化的東西。

我不敢妄談微服務(wù)架構(gòu)的未來走向。立足當(dāng)下，我認(rèn)為目前Spring Cloud+Docker容器化的技術(shù)是用于微服務(wù)架構(gòu)的一個(gè)比較好的選擇。我比較認(rèn)可一個(gè)很有趣的說法是“基因架構(gòu)”，意思是：架構(gòu)從誕生之初就是為了改變的，所以你的架構(gòu)越容易改變就越好。我覺得架構(gòu)的未來會向這條路發(fā)展。

我們的統(tǒng)一開發(fā)平臺的建設(shè)就是基于Spring Cloud技術(shù)棧。

記者：今年在軟件研發(fā)行業(yè)比較熱門的話題是“中臺”，在架構(gòu)層面也有人提出來要做微服務(wù)中臺，對此您怎么看？

梁鑫：去年一個(gè)綜藝節(jié)目帶火了一句話，“盤它”。節(jié)目里有一句 “干干巴巴的，麻麻賴賴的，一點(diǎn)都不圓潤，盤他！”。 后來說到什么就盤什么，也不管是什么東西，能不能握在手中，反正盤就是了。聽起來是不是特別有魔性，然后就有了“萬物皆可盤”這個(gè)段子。這本身其實(shí)只是一種調(diào)侃的講法，也并不會真的有人看到什么就盤什么。有意思的是任何事情都可以再認(rèn)真往深處想一想，你會不會也犯一些看似荒唐的錯(cuò)誤呢？

今年技術(shù)圈最火的一個(gè)名詞就是“中臺”，套用到這兒就變成了“萬物皆可中臺”，一個(gè)名詞到處套，我認(rèn)為很多公司應(yīng)該避免盲目跟風(fēng)，讓“中臺”成為名詞陷阱。

面對一個(gè)新的技術(shù)或趨勢，我們要先了解其來源和根本。中臺的來源需要回溯到阿里。2015年阿里巴巴集團(tuán)啟動了中臺戰(zhàn)略，目標(biāo)是要構(gòu)建符合互聯(lián)網(wǎng)大數(shù)據(jù)時(shí)代的，具有創(chuàng)新性、靈活性的‘大中臺、小前臺’的機(jī)制，即作為前臺的一線業(yè)務(wù)會更敏捷、更快速地適用瞬息萬變的市場，而中臺將集合整個(gè)集團(tuán)的運(yùn)營數(shù)據(jù)能力、產(chǎn)品技術(shù)能力，對各前臺業(yè)務(wù)形成強(qiáng)有力的支撐.

那阿里集團(tuán)為什么要建立一個(gè)‘大中臺、小前臺’的架構(gòu)呢？《企業(yè)IT架構(gòu)轉(zhuǎn)型之道——阿里巴巴中臺戰(zhàn)略思考與架構(gòu)實(shí)戰(zhàn)》一書對此有詳細(xì)介紹。從阿里共享業(yè)務(wù)事業(yè)部的發(fā)展史說起，起初，阿里只有一個(gè)淘寶事業(yè)部，后來成立了天貓事業(yè)部，此時(shí)淘寶的技術(shù)團(tuán)隊(duì)同時(shí)支撐著這兩個(gè)事業(yè)部。當(dāng)時(shí)的淘寶和天貓的電商系統(tǒng)像我們很多大型企業(yè)的一樣是分為兩套獨(dú)立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價(jià)、物流等功能。因?yàn)樯鲜鲈颍⒗锛瘓F(tuán)又成立了共享業(yè)務(wù)事業(yè)部，其成員主要來自之前的淘寶技術(shù)團(tuán)隊(duì)，同時(shí)將兩套電商業(yè)務(wù)做了梳理和沉淀，將兩個(gè)平臺中公共的、通用的業(yè)務(wù)功能沉淀到共享事業(yè)部，避免重復(fù)建設(shè)和維護(hù)。

作為一個(gè)擁有10多年編程經(jīng)驗(yàn)的老兵，我經(jīng)常思考的一個(gè)問題就是系統(tǒng)發(fā)展的規(guī)律，透過其形領(lǐng)會其意，回顧架構(gòu)的發(fā)展，我認(rèn)為可以總結(jié)出一點(diǎn)：“快”。當(dāng)然這個(gè)快是有前提的，比如正確率、資源限制，要在穩(wěn)定、盡量減少資源消耗的情況下求快。

“快”可以再次分解，從開發(fā)的角度來看，編寫代碼要快、開發(fā)要快、功能測試要快、環(huán)境部署要快、服務(wù)啟停要快；從生產(chǎn)的角度來看，程序運(yùn)行的速度要快、高并發(fā)之下還是要快等。

微服務(wù)架構(gòu)之所以流行，因?yàn)榘逊?wù)拆小了，可以高度復(fù)用，不用經(jīng)常編寫和修改代碼，節(jié)省了非常多的時(shí)間；容器化技術(shù)之所以流行，因?yàn)槿萜骰夹g(shù)可以使得生產(chǎn)環(huán)境和測試環(huán)境一致，節(jié)省了大量的環(huán)境部署時(shí)間、減少了出錯(cuò)的可能性，還可以隨意增加容器節(jié)點(diǎn)，增強(qiáng)業(yè)務(wù)處理能力，保證高并發(fā)下的快速響應(yīng)。分布式架構(gòu)也是如此，微服務(wù)架構(gòu)其實(shí)就是分布式架構(gòu)的一種演化。萬變不離其宗，都是追求“快”。

回到“中臺”這個(gè)話題，建設(shè)中臺的目標(biāo)是避免重復(fù)建設(shè)和維護(hù)，快速響應(yīng)需求。后臺和平臺的系統(tǒng)比較穩(wěn)定，一般不輕易發(fā)生變化，而且從穩(wěn)定性考慮，應(yīng)該盡量減少后臺和平臺系統(tǒng)更新的次數(shù)，前端系統(tǒng)因?yàn)橐m用用戶的需求而不斷變化，這樣前臺和后臺在對接時(shí)就產(chǎn)生了一個(gè)求變一個(gè)求不變的矛盾，這時(shí)我們希望在兩者之間建立一個(gè)中間平臺，把前端后臺可重復(fù)利用的東西集中到這個(gè)中間平臺來，重新封裝組合對外提供服務(wù)，這是符合“快”的思想的。

這是中臺的來源和根本，企業(yè)在建設(shè)中臺之前，一定要先了解這些，看所要建設(shè)的中臺是否符合“避免重復(fù)建設(shè)和維護(hù)”的思想，是否符合“快”的原則。

第二部分：微服務(wù)在業(yè)務(wù)中的應(yīng)用需要解決的關(guān)鍵問題

記者：宜信在今年開源了微服務(wù)任務(wù)調(diào)度平臺SIA-TASK，這個(gè)平臺在宜信技術(shù)團(tuán)隊(duì)內(nèi)部有廣泛的應(yīng)用，開源后也得到了很多開發(fā)者的支持。您能否介紹一下這個(gè)平臺的設(shè)計(jì)思路以及核心功能？（設(shè)計(jì)開發(fā)這個(gè)平臺想要解決什么問題）

梁鑫：前面談到中臺，其實(shí)我認(rèn)為“中臺”只是一個(gè)名稱而已，只要符合“避免重復(fù)建設(shè)和維護(hù)”和“快”兩個(gè)原則，叫什么都可以，比如我們的微服務(wù)調(diào)度平臺SIA-TASK，就是一個(gè)很像中臺的系統(tǒng)。

介紹SIA-TASK的設(shè)計(jì)思想之前，我先介紹一下它的背景。無論是互聯(lián)網(wǎng)應(yīng)用或者企業(yè)級應(yīng)用，都充斥著大量的批處理任務(wù)。常常需要一些任務(wù)調(diào)度系統(tǒng)幫助開發(fā)者解決問題。隨著微服務(wù)化架構(gòu)的逐步演進(jìn)，單體架構(gòu)逐漸演變?yōu)榉植际健⑽⒎?wù)架構(gòu)。很多原先的任務(wù)調(diào)度平臺已經(jīng)不能滿足業(yè)務(wù)系統(tǒng)的需求，于是出現(xiàn)了一些基于分布式的任務(wù)調(diào)度平臺。這些平臺各有其特點(diǎn)，也各有不足之處，比如不支持任務(wù)編排、與業(yè)務(wù)高耦合、不支持跨平臺等問題，不符合新一代微服務(wù)架構(gòu)的需求，因此我們開發(fā)了微服務(wù)任務(wù)調(diào)度平臺（SIA-TASK）。

SIA-TASK 使用 SpringBoot 體系作為架構(gòu)選型，基于Quartz及Zookeeper進(jìn)行二次開發(fā)，支持相應(yīng)的特性功能，SIA-TASK 的邏輯架構(gòu)圖如下圖所示：

SIA-TASK是任務(wù)調(diào)度平臺的一站式解決方案，契合當(dāng)前微服務(wù)架構(gòu)模式，具有跨平臺，可編排，高可用，無侵入，一致性，異步并行，動態(tài)擴(kuò)展，實(shí)時(shí)監(jiān)控等特點(diǎn)。

了解任務(wù)調(diào)度平臺，需要先了解任務(wù)調(diào)度。任務(wù)大致分為三種，定期執(zhí)行的任務(wù)；隔固定時(shí)間執(zhí)行但不可并發(fā)的任務(wù)；每隔固定時(shí)間執(zhí)行的但是可以并發(fā)的任務(wù)。任務(wù)之間還可能存在一些次序關(guān)系，比如：串行、并行、分支等。

當(dāng)我們進(jìn)行任務(wù)調(diào)度的時(shí)候，常常會發(fā)生以下的一些問題。

遺忘，一個(gè)項(xiàng)目有跑批任務(wù)，項(xiàng)目下線后跑批流程還在繼續(xù)，直到產(chǎn)生的日志把磁盤空間占滿了才發(fā)現(xiàn)；

單點(diǎn)，某個(gè)項(xiàng)目的跑批流程一直單點(diǎn)，機(jī)器故障后，流程停止運(yùn)行；

依賴，某個(gè)項(xiàng)目的跑批流程A和B有依賴關(guān)系，只能設(shè)置兩個(gè)任務(wù)的時(shí)間錯(cuò)開，如果發(fā)生A延時(shí)，需要手工處理出錯(cuò)數(shù)據(jù)。

我們在設(shè)計(jì)SIA-TASK的時(shí)候，將平臺和項(xiàng)目組運(yùn)行割裂開來。SIA-TASK包括五大模塊，任務(wù)執(zhí)行器，即真正業(yè)務(wù)邏輯需要跑批的業(yè)務(wù)，屬于項(xiàng)目組，項(xiàng)目組在啟動的時(shí)候會把執(zhí)行的任務(wù)暴露成一個(gè)服務(wù)，這個(gè)服務(wù)注冊到任務(wù)注冊中心來；任務(wù)注冊中心拿到一個(gè)任務(wù)，并將它存儲到持久存儲的數(shù)據(jù)庫里，同時(shí)進(jìn)行編排，編排成有依賴關(guān)系的任務(wù)；最后任務(wù)調(diào)度中心拿到任務(wù)編排中心里已經(jīng)編排好的需要執(zhí)行的任務(wù)，進(jìn)行遠(yuǎn)程調(diào)用。

在整個(gè)過程中，任務(wù)調(diào)度、編排、執(zhí)行與項(xiàng)目組是分開的，項(xiàng)目組只需要關(guān)心任務(wù)調(diào)度的業(yè)務(wù)邏輯代碼，剩下的都在SIA-TASK平臺執(zhí)行，相當(dāng)于把每個(gè)項(xiàng)目任務(wù)都原子化了，都變成了一個(gè)個(gè)微服務(wù)。

只把業(yè)務(wù)邏輯留在項(xiàng)目組，調(diào)度、編排、執(zhí)行歸類到平臺中，所有需要代碼處理的東西都通過配置化的方式實(shí)現(xiàn)，也符合中臺“避免重復(fù)建設(shè)的維護(hù)”的思想。

SIA-TASK目前已經(jīng)開源，具體的設(shè)計(jì)思想和功能以及部署操作可以在GitHub查看，地址：?https://github.com/siaorg/sia-task

記者：微服務(wù)任務(wù)調(diào)度平臺（SIA-TASK）適用于哪些場景?

梁鑫：SIA-TASK是基于HTTP協(xié)議的進(jìn)行遠(yuǎn)程調(diào)度的，實(shí)際業(yè)務(wù)中高并發(fā)的調(diào)度處理支持肯定是不夠理想的。如果業(yè)務(wù)是高并發(fā)的、每秒鐘需要喚醒幾千幾萬個(gè)任務(wù)的場景就不太適合使用SIA-TASK。除此之外，其他所有場景幾乎都可使用SIA-TASK。

本文轉(zhuǎn)載自異步社區(qū)。

微服務(wù) 企業(yè)應(yīng)用

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。