DataWorks 如何撐起阿里99%的數據開發？

阿里妹導讀： DataWorks是阿里巴巴自主研發，支撐阿里巴巴經濟體99%數據業務建設和治理，天天數萬名數據開發和算法開發工程師在使用。
從2010年起步到目前的版本，經歷了屢次技術變革和架構升級，也遺留了大量的歷史包袱。技術的創新和業務的發展，相輔相成但也互爲掣肘。存在需求接入慢，代碼牽一髮而動全身，環境複雜等問題，沉痾已久。歷次迭代均未從根基上升級DataWorks，僅僅是一些性能提高、工程結構的優化，減小了重複代碼等，並未促成根本性的技術革命。

本文將探討如何經過當前大熱的微服務架構，來改變DataWorks平臺的現實問題，從繁雜的工程中探索出一條切實可行的技術架構變革之路
1、痛點 讓咱們先來談談DataWorks當前遇到了哪些痛點，這些痛點是倒逼着咱們進行技術變革的源動力。

1.1 沉重的歷史包袱 首先要提的就是歷史緣由遺留的各類問題，DataWorks歷史上多個版本同步開發，先後端技術棧屢次變革，應用一旦上線就很難廢棄，一個對外暴露的api，極可能是5年前開發的，但依然有業務在依賴，一般狀況下連這些古老業務的負責人都找不到了。當咱們的服務正常運行的時候，無人搭理，一旦下線，則可能不知道從哪兒跳出幾個用戶前來投訴。頁面上的功能一樣如此，有時候只是過去不知道哪位同窗開發中引入的一個bug，但也由於咱們的用戶基數龐大，而變成了真理。歷史上曾經出現過的隱藏的很深且用戶寥寥的功能點都有本身的忠實擁躉，一旦被咱們的開發不當心忽視而作丟了，就會迎來投訴和工單，因此DataWorks平臺不愧是千錘百煉磨練出來的大數據開發平臺的標杆，樸素的界面之下隱藏了無數細緻入微的功能點。若是想重造這麼一個被阿里巴巴經濟體無數數據開發工程師驗證（折磨）過的數據開發平臺，都要好好考慮一下這十年來咱們的平臺到底經歷過了什麼。
1.2 複雜的軟硬件環境 DataWorks面臨的運行環境放眼整個阿里巴巴經濟體都是及其罕見的複雜，爲了混合雲（即專有云）這種私有獨立且封閉的環境，三合一版本以後咱們必須放棄依賴彈內成熟的中間件體系，只能尋找那些一樣在三個環境下都存在的技術來支撐。也所以，不少在某個環境下缺失的依賴，若是咱們沒法用開關的方式搞定，或者咱們判斷其複雜度不高，就會經過自研或者去依賴一些開源的體系來解決問題。而公有云上各類網絡環境的問題幾乎都要靠人肉去排查，從天天居高不下的答疑量上就能看到咱們受環境問題的影響是多麼耗費人力。除此之外，前不久中美貿易戰帶來的影響也傳遞給了DataWorks平臺，運行環境須要匹配國產芯片，咱們的進程不但要運行在X86指令集上，一樣也要能運行在基於ARM指令集的國產芯片上。同時爲了知足部分中小企業用戶的購買慾求，敏捷化也是咱們須要去裁剪設計的。

DataWorks平臺雖然龐大且複雜，但在種種更加複雜的軟硬件環境下，也一樣須要可以作到靈活輕便，便於隨時隨地的拆散組合輕裝上陣，以知足不一樣業務場景下用戶的指望。由於挑剔的用戶一向但願用最少的錢購買到最合適的解決方案，DataWorks的競爭力顯然也要從靈活且具有演變能力上尋找將來。

1.3 牽一髮而動全身 工程之間的複雜關聯一直是傳統SOA（Service Oriented Architecture：面向服務架構）發展到必定規模後的噩夢，不管最初的設計是多麼合理，多麼領域清晰，一旦經歷需求的積累，規模的擴張，人員的交替，都將逐步或多或少的面臨着邊界模糊的問題。最典型的例子就是單體服務之間的RESTful類型的API，每每這些API的Schema只能增長元素而不能減小，由於被依賴者並不知道有多少其餘服務正在依賴這個接口，也許某一天某個服務從沉睡已久的服務器中被喚醒，結果發現你的API的Schema變了，那麼必定會把你喊回來修回原來的樣子。先後端分離架構下，這類問題更加突出，因此有的前端同窗爲了減小schema變更帶來的影響，乾脆讓後端透傳一個大字符串，即便裏面夾帶了私貨，也不會使得頁面莫名崩潰。DataWorks平臺也正在經歷着這一過程，發展到必定規模後，每一個功能的改動都要當心翼翼，生怕對其餘模塊形成未知的影響，或者有時候咱們須要把大量時間投入在調研清楚改動帶來的影響上，就算這樣嚴防死守，也依然可能有漏網之魚，最後功虧一簣，一個故障單就可能把爲之付出的努力付之一炬。

1.4 需求變動和頻繁發佈 除了工程架構上的問題，一樣存在問題的還有衆多開發者在合做方面產生的問題，gitlab幫咱們解決了版本之間的代碼衝突問題，但並不能解決產品發佈週期上的衝突。當多個需求都要對外發布上線，尤爲在混合雲，須要按月爲週期產出大版本，咱們一邊要快速上線新feature，一邊還要按照相似瀑布模型的方式將這些功能打包進專有云版本。彈內、公有云、混合雲的發佈節奏大相徑庭，衆多feature按照不一樣的節奏要出如今不一樣的版本迭代中，過去的熔斷機制，更加重了你們在窗口期集中發佈而產生的風險。在SOA中的一個單體服務上，N個開發者開發的M個feature，按照什麼樣的間隔組合發佈上線，使得發佈的節奏既不過於頻繁，也不會由於發佈頻次太少而使得版本跨度太大。若是這M個feature之間又存在依賴關係，則進一步放大了發佈頻次增減之間的矛盾。

1.5 國際化帶來的問題 國際化的問題向來不簡單，時區、夏令時、語言、習慣、本地化圖標等等，對於DataWorks這樣一個遍及全球20個region的平臺來講，這裏面的水深的很。咱們團隊在國際化方面沉澱不少積累，而且將這些優秀的經驗對外開源：github.com/alibaba/rea…。

1.6 依賴耦合 基於SpringBoot的Starter，咱們提高了代碼的複用率，且對於Starter的精心設計，確保同窗們自研踩過的坑不須要反覆由不一樣的同窗來踩。可是這畢竟是不一樣工程中的共同依賴，當這些Starter暗藏bug的時候，凡是使用到這些依賴的工程都將受其影響，甚至某位同窗不當心在修改某個依賴甚廣的Starter的時候寫進了bug，就有可能觸發系統雪崩。

1.7 笨拙的灰度機制 咱們知道搜索引擎在不一樣的算法中尋找最優解的方法，是將這些算法灌裝到不一樣的桶裏，而後引流經過這些算法桶，經過各類指標的對比，將其中最優的算法挑選出來。這是一種基於架構設計的灰度機制，並不須要人爲干預流量的導向，從入口處進來的不一樣搜索天然而然的就流過了不一樣的算法桶，隨着海量的訪問，最優解必然得以顯現。可是目前的SOA架構下灰度每每依賴於提早設計好的開關，DataWorks即是如此，當咱們須要驗證某個功能是否存在問題，傳統的辦法是找到前端同窗，讓前端設計一下開關機制，篩選一部分用戶進入到新設計的功能裏面，通過一段時間的試跑和調整，逐步把問題解決掉，同時對用戶的影響也能夠控制在比較小的範圍。但這顯然不是一個能夠反覆的，隨意的，天然而然的灰度機制。人爲的干預，爲灰度而耗費的設計開發，使得一次灰度的成本居高不下，有些時候咱們的同窗甚至由於想避免麻煩，而忽視作灰度驗證。當咱們想經過灰度來驗證的功能很是的局部，或者用戶無關，工做空間無關的時候，或者咱們壓根不知道哪些用戶會使用到某些功能的時候，灰度機制也會在傳統架構下失效，即便咱們想去設計，也無從下手。 對於SOA下單體服務來講，灰度沒法藉助於架構的設計，可是DataWorks平臺下底層調度服務Alisa的Gateway集羣因爲機器數量龐大，也能夠實現基於架構設計的灰度機制，幾百臺Gateway中，咱們能夠取出一小部分，部署待驗證的新版本，任務下發後經過不一樣版本的比對，尋找潛在問題。但這並不是DataWorks平臺後端的常態，幾乎全部單體服務並無部署到這麼多機器中，所以這也幾乎是大多數SOA的狀態，都面臨着不能基於架構設計，而要基於人爲干預的灰度機制。

1.8 外部關聯服務的不肯定性 外部關聯服務複雜多變，且不可靠不穩定，隨時會宕機或者網絡中斷，甚至是外部服務升級忘了通知咱們，從而致使故障頻繁。這一點對於數據集成這樣一個在幾十種引擎，數千個數據庫實例中搬運數據的應用來講尤爲深有體會。爲了應對外界服務的不肯定性，咱們將有衆多依賴的自身應用設計的魯棒性特別優異，然而這會增長咱們自身代碼的邏輯複雜度，偶然出現的問題也會被代碼的魯棒性掩蓋，問題若是不及時處理，就會逐步積累，當全部出現故障的條件湊齊以後，一次性爆發一個P1級別的大故障。

1.9 緊缺的前端 DataWorks研發平臺還面臨着前端人手不足的問題，這是富交互產品的研發團隊都面臨的共通問題。前端受制於交互的不一樣，樣式的迥異，業務的區別，以及研發同窗各自對業務理解上的差別，以致於可以複用的前端組件極其有限。在浩如煙海的前端類庫、組件、樣式中，可以實現成本轉移的寥寥可數。在先後端分離，基於主流前端框架的設計模式下，相較於歷史上的先後端一體設計體系下的用戶體驗是有提高的，然而這都是基於前端開發同窗辛勤的勞做，一點點的調整樣式和交互換來的成果，這裏歷來沒有捷徑可走，而咱們只能寄指望於可以複用前端開發同窗的研發成果，讓每一次設計都不要成爲只使用一次的勞動。

2、合做與競爭 DataWorks研發平臺衆多功能涵蓋了數據開發工程師的平常工做，用戶在咱們的平臺上終年累月的伏案工做，對一些功能點的設計有本身的切身體感，而這些體感是咱們平臺的研發感覺不到的。PD和咱們的UED去收集需求去使用去親自感覺，然而畢竟不是專職於數據開發自己，所以很難體會到數據開發工程師長期使用後的那種細微的挫敗感。再到細分的垂直業務市場，不一樣行業下如何使用咱們平臺，差別更是有天淵之別。面向金融，銀行，政府，大型國企，互聯網公司，傳統企業，民營，教育，等等，他們的用法都是徹底不一樣的，有的行業甚至就不知道拿到DataWorks平臺後該作什麼。用戶的需求千差萬別，用戶的心智也處於不一樣階段。 所以，在咱們無暇一一顧及的領域，前方的交付團隊或者公司，使用DataWorks平臺應用到具體的行業中，而後再將行業的專屬需求帶回給咱們的PD進行分析。咱們平臺自己也會開放一些Api給予前方團隊包裝成產品提供給特定領域的客戶，幫助客戶解決實際問題。 新的產品規劃還在不斷制訂之中，引擎團隊設計好本身的產品也須要在DataWorks平臺上下降用戶的上手難度，若是永遠只是DataWorks平臺的開發同窗按照排期逐步完成這些接入和訂製需求，平臺註定難以持續發展壯大。所以，從先後端架構層面，從無數的合做和競爭場景出發，都迫切須要咱們進行一次針對自身的技術革命，完全從SOA中解放生產勞動力，引入更多的用戶側的研發力量，幫助平臺向更健全的方向發展。

3、架構的變革 任何一種技術的變革都是按部就班的，這和Spring之父Rod Johnson秉持的理念是一致的。他提出了「輪子理論」，也即「不要重複發明輪子」，這是西方國家的一句諺語，原話是：Don't Reinvent the Wheel。除此以外，經過長期的實踐後他在著做中總結闡明瞭循證架構的思想，即「沒有最好的架構，只有最合適的架構」。這是架構界進化理論的雛形，意味着咱們的架構要不斷的演進去配合多變的業務需求。 傳統的SOA下，服務趨向於穩定和集中，單體服務之間是平等的，或者至少在共通的結構上是相似的，服務與服務之間經過網絡通訊進行依賴。SOA下每一個單體服務多是多個開發者圍繞着進行合做開發，所以替換任何一個單體服務都是一件傷筋動骨的事情，當有大的技術棧的變革，例如從WebX 3.0升級到SpringMVC，從SpringMVC升級到SpringBoot，人力成本消耗都是巨大的，升級週期動輒以年爲單位，更不用說假設咱們想用Go語言或者Python的Django框架來替換J2EE體系下已經設計好的web服務，這幾乎是不可能完成的任務。也意味着當咱們進入了這個技術體系，就很難再從這套體系中脫身，更無從談起架構的演變和進化。 在傳統SOA下，提高工程效率的手段是極致的代碼複用，凡是可複用的代碼，都抽取到二方包中設計成類庫讓不一樣的單體服務依賴調用。雖然配置愈來愈複雜了，但的確減小了「重複發明輪子」的事情。 還有一個辦法，是如我在2015年時候嘗試新的架構設計時候採起的方法，即：能抽象成二方包的抽象，不能抽象的經過自動化代碼生成工具自動生成。一套演練成熟的SOA架構工程，從目錄結構到配置組裝都幾乎是穩定不變的，即便有變化，也都是按照MVC三層架構進行微調，所以咱們能夠把一些沒法抽象的，或者包含了複雜邏輯，須要靈活調整的代碼經過自動化代碼生成工具來生成，而且儘量冗餘代碼的功能，讓開發者從生成的工程代碼中儘可能作減法或者根據業務邏輯只修改最少許的代碼，從而提高了工程的整潔度和開發效率。 除了代碼的複用，還有服務的複用，咱們設計了一些中心化的單體服務，用於將複雜邏輯或啓動較慢或須要緩存，等等這樣一些功能封裝在這些核心服務中，進一步減小圍繞中心服務的其餘應用的體量和複雜度，固然這也可能會引入單點可靠性的問題，但要確保核心服務的穩定可靠，在必定規模的服務體量下並不是難事。 即使如此，SOA在效率上的提高依然是有限的，初期工程創建的快速高效並不表明長期業務開發後還能維持這樣的效率持續發展。前文描述的痛點逐步展示且缺少行之有效的解決辦法，開發者因爲整齊劃一的使用同一套技術棧甚至同一套工程目錄樹結構，雖然在協同的時候更加默契，但也消滅了前沿技術在團隊內的賽馬機制。研發同窗在一套逐漸古老落後的框架下研究怎麼壓榨出最後的效率和性能，但每每忽視了也許換個框架換個技術棧甚至換個語言，就會帶來質變。所以，當基於谷歌的K8S體系成長的生態圈逐步成熟以後，遵循「沒有最好的架構，只有最合適的架構」的思想，咱們開始思考如何將DataWorks的技術方向轉向靈活多變的微服務架構。

3.1 微服務架構 提到微服務，理所固然要和雲原生關聯，所謂雲原生（Cloud Native），包含了以下三點： 1）DevOps 開發和運維再也不是分開的兩個團隊，而是你中有我，我中有你的一個團隊。 2）持續交付 持續交付的意思就是在不影響用戶使用服務的前提下頻繁把新功能發佈給用戶使用。 3）容器化 容器化的好處在於運維的時候不須要再關心每一個服務所使用的技術棧，每一個服務都被無差異地封裝在容器裏，能夠被無差異地管理和維護。 知足上述三點的雲原生環境，對於微服務來講自然適配。當一個產品發展到必定規模，且具有了足夠體量，擁有數量衆多的子產品，以致於交互和依賴關係日益複雜，則微服務架構將爲這樣的產品下的工程羣帶來顯然易見的好處。本文不對微服務的基本概念和泛泛的常規作法作詳細介紹，網上此類文章汗牛充棟，這裏僅推薦兩本不錯的書《微服務設計》（前幾章概念講解還能夠，後面部分通常）和《微服務架構設計模式》，前者適合初步瞭解，後者適合進階。本文僅討論DataWorks在新的架構下的作法，從實踐中得真知。 對於DataWorks研發平臺下衆多產品應用來講，微服務架構方向的改造也許不是能破解全部問題的萬能鑰匙，但必定是當前開發模式所遭受的病痛的解藥。

★ 3.1.1 認清自身 DataWorks研發平臺屬於典型的PaaS應用，固然也有數據服務這樣的產品作到了SaaS層。傳統SOA遇到的痛點，以及未來咱們要對客戶開放的定製化能力，須要藉助微服務架構來應對，逐步將研發重心從PaaS移向SaaS。 當咱們採用基於K8S容器化的微服務架構以後，開發者能夠在咱們自主研發的微服務平臺中集成DataWorks平臺開放出來的基礎OpenAPI，也能夠集成外部應用的API，在微服務中進行數據整合和業務邏輯的編寫，最終暴露出一系列在平臺前端可訪問的API，供前端功能模塊使用。在這個過程當中，咱們能夠順便化解前文提到的一些痛點。

★ 3.1.2 解決痛點 以歷史包袱爲例，咱們能夠逐步將年久失修的，陳舊的SOA單體服務中包含的功能進行替換，將這個快變質的大餅切割成一個個低耦合的小餅，實現逐步的更替，而非採用長週期的一次性總體替換。陳舊的工程沒必要再去發展更新，僅維持基本的運行，避免了總體替換帶來的週期長，故障多，回滾困難的問題。並且咱們能夠很方便的經過金絲雀發佈來驗證新上的「小餅」是否成功替代了「變質大餅」中一小部分模塊的功能，經過藍綠部署將有問題的小餅快速及時的撤下，也能夠作到經過ABTest來驗證哪塊小餅的性能更好、設計更合理。 再以個性化需求爲例，當咱們開放了和DataWorks業務耦合的微服務平臺，具有自研能力的業務團隊（如數據/報表開發團隊）就能夠藉助微服務的設計，快速的將本身的需求設計到咱們DataWorks平臺後端，同時前端頁面咱們也會留出「自留地」（下文描述的插件化）供業務團隊自行設計開發。引擎的接入一樣能夠參照此模式進行，DataWorks下一部分模塊的接入能夠更加的傻瓜化，好比檢查器，好比功能強大的自定義節點等，用戶根據文檔通過簡單的開發後就能夠快速自主接入使用，但對於更加訂製的功能，例如當前ADB引擎正在DataWorks平臺上進行的可視化建表部分的設計，因爲複雜度很高，所以必須經過微服務對接前端插槽（下文描述）來進行開發，從而實現複雜業務邏輯的自主自助接入。 再來描述一下基於架構的灰度機制，在微服務架構下，能夠輕鬆的實現藍綠部署，金絲雀發佈和ABTest，咱們的微服務設計應該是儘可能面向領域的（固然不太可能作到100%的面向領域），高內聚低耦合依然是單個微服務的設計宗旨。咱們能夠發佈多個版本的微服務用來測試某個領域的問題是否獲得某方面的改善，也能夠發佈多個徹底基於不一樣框架甚至是不一樣語言設計的微服務，來驗證某個領域內誰是最優解。藉助於基於架構的灰度機制，基於雲原生，這一切都將很是高效且可靠，即便出現問題，也能夠快速撤下有問題的微服務，避免擴大影響。 還有其餘一些痛點，不一一描述基於微服務架構的解法，好比牽一髮而動全身的問題，在DataWorks平臺全面構建到微服務架構上以後，這個問題天然就會消失。每一個同窗均可以分管多個面向領域的足夠小的微服務，當某個接口須要從新設計，沒必要當即替換老的接口，而能夠將這個接口下對應的微服務低成本的從新設計，等待流量切換到新的微服務後，再逐步下線舊版本微服務。再好比SpringBoot下由Starter引入的耦合性，到了微服務框架下，將會經過服務發現來解耦，再也不須要經過代碼層面的依賴來耦合關聯。

★ 3.1.3 循證架構 再回過頭來說講本文還沒說起的一塊內容，咱們的微服務究竟是什麼？微服務固然不是必定要以微小爲特徵，它仍是一個SOA，只不過會更加輕量級更加面向領域。以機器人工廠爲例，該產品有一個功能是讓用戶配置一些意圖跳轉到用戶本身設計的應答邏輯中，這部分正在擁抱微服務架構，完成上線後，用戶能夠根據輸入來設計本身的應答微服務，且語言無關。這樣作還能夠避免用戶的微服務在設計不良的狀況下崩潰，不至於影響到其餘正在運行的微服務，機器人工廠的這個場景也能夠設計成FaaS，用戶只須要編寫函數就能夠完成本身的應答邏輯，且按訪問量來計量使用狀況。

DataWorks團隊設計的微服務平臺，充分擁抱瞭如今大熱的Service Mesh，即服務網格，經過Mesh將一部分工做封裝在前置的微服務裏，這些系統級微服務與開發者設計的微服務運行在同一個pod裏，使得開發者設計的微服務更加簡單，Mesh更像是Spring框架下的HandlerInterceptor或者Filter，面向AOP編程的開發者擅長在工程裏開發攔截器和過濾器，到了集成了Service Mesh的微服務框架下，能夠方便的使用系統級微服務替代一部分傳統攔截器的工做。好比登錄跳轉、權限控制、服務發現，好比限流、監控、日誌聚合等等。 讓業務專一於業務自己，避免諸如登陸配置、日誌配置等對工程開發的干擾，同時咱們還設計了不一樣語言的DMF（DataWorks MicroService FrameWork）框架羣，幫助開發者快速上手微服務的開發。「沒有最好的架構，只有最合適的架構」，未來咱們也會開放DMF的開發設計，讓更多業務方貢獻本身的「最合適的微服務框架」。爲了更好的支持和咱們業務強相關的DevOps，咱們開發了DataWorks微服務平臺（DMSP：DataWorks MicroService Platform），用於管控微服務的部署和發佈，以及服務治理等其餘運維工做。

3.2 前端的體系配合 前面提到的插件化指的是咱們前端團隊設計的XStudio插件化方案，插件結合後端微服務，成爲一套總體的解決方案，DataWorks平臺的前端團隊但願基於此，嘗試探索出一套提高前端研發效率的方法論。XStudio插件化基於 single-spa 和 qiankun框架實現。該框架提供了多實例模式，插槽機制和可視化插件編排等重要特性，進一步提高了插件開發的效率。整套插件化的示意圖以下：

前端同窗在基於XStudio插件化設計的頁面上，留好插槽，插槽裏面能夠是一個按鈕，也能夠是其餘任意類型的組件，這個組件後面綁定一個微服務，咱們能夠將插槽裏面的內容連同後端的微服務一併替換，實現頁面功能的快速組裝，從而實現一次開發的多處使用。同時，插槽裏的內容也能夠由業務開發團隊來提供，那麼業務開發團隊也只須要自行設計先後端一體的這樣一個插件來放置到前端插槽裏，實現個性化需求的訂製開發。 在傳統的插件化設計裏，開發者們要麼提供一個遵循某種接口協議的二方包、要麼提供一系列遵循某種協議的API再由SOA架構向前端輸出。這帶來的問題要麼是對SOA服務有侵入，要麼影響了SOA服務總體的安全性和穩定性問題，要麼受限於編程語言、要麼毫無靈活性，而微服務&插件化完美的解決了這類問題。 對於須要佔用更多頁面空間的設計，咱們能夠將大片區域設置成可替換組件，好比上圖的編輯器部分，讓用戶自行替換掉這片區域的頁面內容，跟後端一個或者多個微服務關聯起來嵌入到DataWorks的前端頁面中，方便業務團隊實現更復雜的自定義業務邏輯。當前ADB的可視化建表部分的設計正是遵循了這套方案，由ADB引擎團隊自行開發接入DataWorks平臺中。 同時，前端體系中還有重要的一環是受訪的數據監控和報警，咱們設計了各類維度的報表和指標監控，不管是本身的業務仍是外部業務團隊寫進來的組件，不用多寫一行代碼，均可以經過「自動化全量埋點技術」，觀察和了解組件的使用狀況。 3.3 插件的運行 當前咱們已經將部分前端基於XStudio架構的組件與後端微服務配合起來實現了插件化封裝，比較優秀的如Terminal，DWEditor，目錄樹，檢查器等插件。以Terminal爲例，該插件設計完成後，插入到不一樣的Studio中對接不一樣的引擎，而且能夠根據用戶的使用狀況自動拉起或者銷燬容器實例，從而節省運行資源。 Terminal插件接入到多個引擎，不管是前端仍是後端的微服務都不用針對引擎進行額外的開發，從而實現開發效率的提高。插件化的封裝設計，不只能夠節約開發資源，並且能夠實現多個應用集中使用一套微服務的目的，而彈性編排和自動擴縮容機制保證了服務的性能，同時不至於浪費機器資源。

此外，基於微服務架構，咱們還能夠構建SaaS的一些實現，例如FaaS、BaaS（Backend as a Service），以及BFF（Backend For Frontend）。以BFF爲例，移動端的DataWorks應用BFF後，能夠減小移動端H5頁面的網絡消耗，將後端多個微服務提供的接口經過Gateway組裝後提供給移動端，實現微服務的聚合。若是經過BFF作了SSR（Server Side Render：頁面同構，至關於在服務器端直接渲染成html輸出到瀏覽器），則能夠進一步下降移動端的渲染性能消耗。

★ 3.3.1 DataWorks微服務平臺 先後端一體基於DataWorks業務的插件化，也是咱們堅持要自研設計開發DataWorks微服務平臺（DMSP：DataWorks MicroService Platform）的重要緣由。DMSP打通了前端組件的發佈和後端微服務的綁定關聯，經過Swagger這樣的技術手段成功使得先後端在部署後能夠迅速成爲一個業務插件。讓團隊的先後端均可以在DMSP裏面實現DevOps，以持續交付的方式源源不斷的將新功能發佈給客戶。 尤爲值得說明的是，DMSP一樣是針對三大環境的，即彈內、公有云和混合雲，插件開發完成後，咱們要經過DMSP持續交付到公有云多達20個region的環境中，還要可以實現微服務在專有云的統一打包部署。而且，DMSP還要讓開發插件的同窗儘可能對複雜的外界部署環境無感。 將來咱們指望整個DataWorks平臺的大部分頁面內容都基於插件化設計，從而解決前文痛點裏面提到的問題：「靈活輕便，便於隨時隨地的拆散組合輕裝上陣」。架構驅動的不只僅是開發模式，並且勢必還將影響到整個產品的藍海。 4、構造生態 構造生態的重要前提是要有競爭，要有優勝劣汰，構造生態的同時就是在構造能夠演變，能夠適用進化論的技術體系。做爲「循證架構」的昇華，微服務架構顯然在進化方面更勝一籌，循證架構是一種自上而下用進廢退的技術演進路線，而微服務架構則是一種自下而上優勝劣汰的技術演進路線。容器化實現了語言無關，框架無關，每一個微服務都被無差異地封裝在容器裏，從而能夠針對一個功能開發出多種微服務，相似算法桶的優選機制，從這些完成同一個功能的微服務中挑選出最優解。在理想狀況下，無需上層架構師的主動干預，應用就能夠在一段時間的進化後自組裝成最佳的實踐。固然這只是理論上的情形，咱們身處的現實世界受不少外界因素的干擾，實際狀況下，受限於開發者的技術素養、外界依賴的良莠不齊，甚至是受限於KPI的導向，都將使得這種理想下的最佳實踐沒法達成，但微服務架構給予了咱們能夠經過團隊的協做和努力，從而無限接近理論中的最終解的能力。 在微服務架構下，前文提到的垂直業務的定製開發也將成爲一種可能性，面向行業的交付團隊能夠利用DataWorks平臺提供的插件化能力，爲客戶訂製徹底適配行業特徵的智能研發平臺。進而在DataWorks研發平臺上營造一個有活力的創新生態圈，爲客戶提供更加豐富多彩的選擇。架構將驅動整個生態圈的優勝劣汰，從而不斷向更有競爭力的方向進化。 咱們DataWorks研發團隊也寄指望於在這套架構之上，實現彈內彈外的雙贏模式的合做，推進雲智能事業羣下的產品造成協力。 5、先後端組合拳 所謂架構，不只是技術上的事情，同時也要對人力的分配組織提供整套的指導方案。在應用了微服務架構以後，DataWorks研發團隊的職責顯然不能僅僅侷限於平常的需求開發，做爲微服務架構的倡導者，在推動架構的同時我也對團隊的先後端職責進行了思考。首先先後端須要拉出一個框架小組，經過指導前端組件和後端微服務的設計來影響整個架構的進化，團隊內須要有關注面向領域設計的研討，分析每一個插件是不是領域性的，同時須要有把關的同窗，審覈第二方（彈內非本團隊的開發者）和第三方（彈外的交付團隊或者來自客戶的行業開發者）提交的插件設計，防止不良應用破壞體系構建。 同時，微服務架構因爲語言無關性，還抹平了一些技術上的鴻溝，前端同窗不少擅長nodejs，也能夠在微服務的設計中一展身手，更使先後端在技術上的交流和溝通會更加有默契。咱們的產品線中還有一個特殊的產品：AppStudio，專職於WebIDE的研發工做，未來不管是數據服務提供的數據出口，仍是FaaS裏的函數，仍是微服務自己的開發，均可以與AppStudio結合，由用戶自主開發，能夠徹底不用脫離DataWorks全域大數據平臺，就從數據開發到報表設計，再經過微服務編寫業務邏輯，達成數據輸出的目標，一站式完成用戶的訂製需求。

上圖是將來的團隊職責分工的一個構思，先後端研發同窗在這套組織架構下，打出一套組合拳，直擊痛點問題，幫助用戶攻克技術難關，實現生態的繁榮昌盛。 6、展望將來 技術和架構的將來是什麼樣子的？在個人理想中，軟件工程的研發技術應該是一個沒有止境和邊界，且愈來愈智能化的領域。DataWorks的產品中已經有不少開始向智能化的方向前進，好比基於VSCode應用了Markov算法的智能編程插件。研發團隊的將來很大程度上取決於體系的架構，咱們應該鼓勵創新，鼓勵對技術前沿和邊界的探索，不該該人爲的製造太多規約從而限制了思考的天馬行空。若是有一天，智能化編程終於開始替代人工開發，那麼經過改變架構的設計，研發人員也必定能夠在新的架構中尋找到新的職責。 世界是變化的，也是有規律的，咱們的技術願景應當是爲這個變化的世界構建出成熟且不斷進化的工程體系。面向將來，擁抱變化，爲了沒法計算的價值！歡迎識別下方二維碼，瞭解團隊信息，加入飛天大數據交流羣和DataWorks產品進行交流 上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/

本文爲阿里雲原創內容，未經容許不得轉載。