前言
經歷了半年多的996 + 9107，快到12月份的時候終於將項目完成了。公司三年前就要向新零售領域發展，經過不斷的努力和摸爬滾打終於有了一個可喜的成果，其中的心酸苦楚着實不易！承蒙領導的關愛和信任，讓我負責電商中臺的建設工作，感激之情無以言表，唯有做好工作予以報答！我是一個喜歡總結的人，就以這篇文章記錄和分享一下我在今年的電商中臺的建設中的一些感悟和體會。
本文將會以中臺化建設中遇到的種種情況和問題進行闡述和分析，會存在一些侷限性。才疏學淺，水平不足，文章偏頗之處還請各位前輩、大佬多多指點。
1、爲什麼要做中臺
1.1 我對中臺的理解
中臺這個概念起源於美軍的作戰體系，強調“支撐”、“高效”和“靈活”，最主要的目標就是提供強有力的後勤保障。兵馬未動糧草先行，商場即戰場，在對等的外界條件下一場戰爭能否打贏往往看你的後勤保障能否到位。所以中臺的建設更多的是爲企業提供後勤保障。具體到互聯網的技術開發中來看是這樣的：將已經龐大、複雜的業務細化和拆分，避免重複造輪子，解決開發效率問題，降低創新成本，縮短工期；從而讓公司的業務方快速進行市場驗證和試錯，讓公司在和自己的友商競爭中處於絕對優勢。
比如在市場中發現了一個新的商業方向，人力資源相同的情況下需要100天才能開發完成。友商的優勢是先於我們發現了商機，並且提前20天進入了開發，缺點是他們沒有中臺建設，一切都要從頭開始。 而我們自己的公司缺點是後發現商機，但優勢是我們有中臺提供支撐，其中有80%的功能是可以完全複用的，剩下的功能開發只需要20天就可以完成。 也就是說公司只需要20天就可以將產品上線，對比友商他們還要60天才能完成開發。這些富餘出來的時間會收集到足夠的市場反饋，而友商的系統上市就面臨過時的風險。這種強大的驅動力能爲我們的公司在市場競爭中提供強大的優勢，時間就是一切！
1.2 中臺帶來的好處
綜上所述，中臺帶來了如下好處：
- 快速推進新業務上線。
- 快速試錯、驗證商業方向準確性、快速響應市場變化。
- 降低人員成本，研究性開發與業務性開發分離。
- 提高代碼的可複用性。
對於第四點“提高代碼的可複用性”在上面的例子中是一種隱性的體現，對於非技術出身的讀者可能體現的有些不明顯，下文還會有更爲詳細的闡述。
1.3 中臺爲業務賦能
1.3.1 理想狀態下的技術部與業務方
中臺是一個爲公司提供後勤保障的角色，那麼誰是我們的部隊和士兵呢？我的答案的是公司中的業務方。業務方去銷售我們公司的產品，他們就要和“戰場”中的友商拼命廝殺，買了我的產品客戶就不會用你的產品，我多喫一口你就少喫一口。市場就這麼大，客戶就這麼點兒，有你沒我像極了一場戰爭。業務方在面對瞬息萬變的市場環境時肯定需要根據市場反饋及時做出業務上的調整。通常來講中臺提供的能力是可複用的，特定業務上的調整並不會造成多少影響，我們只需要調整業務代碼即可。這種情況下工程師們加的班都是有意義的，技術部門與業務方相輔相成共同完善產品，和諧了~
這種理想狀態很少見，需要公司的決策者有大格局。往往這樣的公司都是很成功的，因爲決策者瞭解互聯網科技公司生存的根本是：技術。如果公司的技術不過硬，靠什麼在競爭中生存？穩紮穩打，一步一個腳印，不走彎路纔是捷徑。急功近利還是要付出一些代價的，要麼買成熟的中臺技術，要麼後期下血本去對技術做中臺化升級改造。
1.3.2 現實狀態下的技術部與業務方(絕大部分企業存在的情況)
生存是企業基本底線，盈利是企業的最終目標。我相信這個觀點大家都會同意，依據這條公理老闆都會給自己的業務部施壓：銷售要出業績，每個季度要做考覈、定目標、評績效等等。業務方在此情景下爲了完成銷售目標他們會絞盡腦汁來拉取客戶、迎合市場；新奇的想法和需求會一個個飄來，不論合理與否。
情況1：中臺化已經完成。
在這種情況下中臺爲業務賦能時，只要不被業務方的需求侵入中臺能力，一切都還好，只更改業務中臺的代碼即可。如果要是業務方的需求已經需要中臺去修改自己的能力模塊了，那麼事情可能會慢慢朝着不和諧的方向發展(中臺化不健壯)。
情況2：中臺化進行中。
一件可怕的事。業務方與技術部門會爆發激烈的衝突。通常一個公司中，開發資源是很有限的，他們去參與中臺化的項目就肯定沒有時間去維護、迭代業務方的需求。業務方身上背的業績往往無法完成，就會反覆和技術部門衝突，矛盾也會越來越大。此時公司往往會很動盪，這也是常說的不做中臺等死，做中臺找死的原因。這種情況下，公司的決策者需要作出取捨：你想用空間來換時間還是以時間來換空間。流的血都是欠的債，只要公司的中臺化能夠完成，那麼公司將煥發一次新的生機，整體技術實力也會成倍提升。
1.3.3 如何賦能
從前兩個小節可以看出，中臺從建設到賦能不是一件容易的事。中臺賦能需要看重2點：
1 關於人
業務方與技術方需要妥協。在這個項目中我們遇到了一些很棘手的問題，就是出在人身上的。有些產品需要是需要業務來推進技術去實現的，這是正常的產品需求；但另一些產品需求是和技術有強關聯性的，應該由技術人員來推動產品去設計。在項目中如果業務方或產品人員過於強勢，輕則破壞中臺架構的合理性和健壯性，重則導致項目嚴重延期。
2 關於技術
務必統一技術框架，達到各個部門通用，減少各個部門間的學習成本。
技術統一，共性剝離，開放共建，擁抱變化，服從指揮。中臺爲業務賦能，這5點我認爲缺一不可。
1.4 你的企業是否適合中臺化改造
期望進行中臺化改造的企業一般來講會有這樣的情況：公司目前或在不遠的將來會出現大型、複雜的生態系統，如果不中臺化改造會出現重複建設的問題，隨着業務的不斷擴大項目變的會約來越多，越來越臃腫，需求迭代越來越慢，項目管理變的越來越困難。中臺化從另一個角度看是一個企業技術體系瘦身的過程，畢竟“胖”不是一件好事兒。如果存在這些需求，那麼公司需要中臺化改造。然後我們再從公司的性質進行分析：
A 僞互聯網類型公司
這類公司你說他是互聯公司吧，有些牽強，說他不是吧他又做了一些互聯網公司要做的事，這類公司佔比很多。
售賣IT服務，對技術的要求不高，急於擴展業務，偏銷售傾向，服務於傳統行業人羣，又和互聯網打一些交道但不是很多。這類公司往往對互聯網技術的使用浮於表層，一些互聯網技術他們也用，但不會考慮互聯網帶來的高併發和服務器性能問題，緩存的使用佔比通常在20%以下，消息隊列也是可有可無，對於核心的服務治理框架通常缺少自己的積累和沉澱。如果公司還健在，現在往往也在進行中臺化改造。
特別巧，我所在的公司正是這種類型。公司高層認識到了未來的發展趨勢，下了很大的決心進行中臺化改造，今年終於有了一點成效。但就客觀的說，中臺化的程度並不徹底。CTO規劃的電商中臺、營銷中臺、訂單中臺等等核心技術部門方向是很正確的但是每個中臺的技術框架與核心底層代碼並不通用，這無疑會加大技術人員的學習成本。中臺化即是後勤保障更是一個“制式武器”，在戰場上武器如果是萬國造，打起仗來肯定會掣肘。
出現這樣的問題，我得出的結論還是在人的身上。每個中臺的負責人都有自己的個性，他們會按照規劃去做，但是如何做得“我”自己說了算，也就是說並沒有完全服從指揮。這種情況事實上很常見。
所以結論是：適合。這類公司一旦中臺化完成也就完全變成了純互聯網公司，對比自己的友商將有更爲強大的競爭力；競爭力的強弱會根據其中臺化的徹底程度來決定。
B 純傳統行業公司
使用的技術以SpringMvc、SSH等單體應用框架爲主，提升性能以擴展機器爲主，很少用互聯網技術，基本不涉及服務治理，會簡單的使用緩存。這類企業不在少數，其中還不乏一些知名的電商公司。 這類公司的系統中魚龍混雜，有一些子系統還是外包公司做的，或者直接購買第三方現成的項目，可維護性很差。
如果單純的只做政府項目、內部系統，我覺得沒有中臺化的必要。
C 以單體應用爲主體技術的電商/互聯網公司
使用的技術與B類公司一樣，都是以SpringMvc、SSH等單體應用框架爲主，以幾十臺服務器以內的小集羣模式存在，流量峯值在1萬以下的中小型電商。他們起步早，同時已經在市場立足；比較有代表性的是惠家有、樂友孕嬰童等(2018年前瞭解到的)。核心項目中的代碼都是自己研發人員開發的，周邊的進銷存系統、BI系統基本是買的或外包人員開發的。
這種類型，中臺化改造的代價是最大的。業務運行的很好，也沒啥毛病，在流量高的時候多買幾臺阿里雲的服務器就可以解決。如果進行中臺化改造，短時間內恐怕無法完成(我們公司中臺化改造至今已經3年，無經驗可循只能公司內部反覆摸索)，無論是時間成本還是風險成本都很高。但如果不改造又會制約企業的戰略和未來的發展，相當糾結。
我對這種情況的看法是這樣：不要再內部摸索了，儘量去找成功的案例，能花錢解決的問題都不是問題。中臺化就已經很難了，同時還要面對爲老項目進行微服務化重構的任務，而且老項目還不止一個！個人感覺成功的希望比較渺茫。假如公司獲取了現有的中臺化改造方案，將工作重點放在老項目的微服務化重構上，人力資源成本也會很高。按照現在的市場行情來看，一個工作經驗在4年以上，同時微服務開發經驗在2年以上的人，通常薪資水平會在2萬上下，公司承擔的人力成本會在2萬6左右，那麼一個人一年的成本約爲35萬。根據公司項目的大小不同，這樣一個團隊的規模會維持在30到40人，一年的成本約爲1000萬到1500萬之間。
這裏還未考慮HR組件團隊的時間成本以及公司內部的老員工是否全力配合。中臺化如果一年之內能夠徹底完成，簡直是奇蹟。所以各位大佬還是要謹慎。
D 創業型公司
主要看創業者的心態。如果想摟一筆錢就把公司賣給天使們，那無所謂什麼中臺化，依託於業務怎麼快怎麼來；如果是將它當成自己的事業和夢想，我覺得有必要進行中臺化，讓他爲你的夢想保駕護航。公司在創始之初就以中臺化的方式來支撐和設計，那麼系統整體的健壯性、可擴展性和穩定性一定會很強。你的任何業務都需要以技術來進行支撐，技術纔是公司的根本所在。在15年的互聯網大潮中，很多創業公司如雨後春筍一般出現，但又很快消失掉了。根本原因就在於其技術基礎薄弱，光靠PPT是贏不了市場的。那時候很多公司的商業方向都很好，不少都拿到了A輪投資；但在進入B輪之前基本都死掉了。因爲投資人會不斷圍繞着你的商業方向提出新的市場需求，市場在不斷變化而你的技術所支撐的系統無法快速響應這種變化，投資人會怎麼想？在這個時期公司擴招了員工，資金鍊一旦斷裂公司會非常動盪；人心不安，離關門也就不遠了。
2、中臺的團隊形態與定義
2.1 中臺團隊常見形態
中臺的建設需要一個統一的組織來領導，從上而下去推動，否則中臺化很難落地。這就涉及到組織架構上的調整，需要建立一箇中臺團隊。中臺團隊的常見形態有2種：技術委員會和平臺架構部。
- 技術委員會
業務流派的中臺團隊常見形態，由每一個項目組的負責人或技術Leader來共同組成，承擔組織和協調的任務，執行人員分散在原有的各個部門裏。實際項目中溝通和協作成本很高，中國人的特點是喜歡看熱鬧，所以實際產出並不高，複用的價值體現的並不多。當然了，每個公司的企業文化是不同的，這種情況並不一定存在。
- 平臺架構部
技術流派中臺團隊的常見形態，公司需要投入的成本比較高，通常由運維架構師和系統架構師共同組成，主要負責核心底層框架的封裝工作和探究性質的技術開發工作。平臺架構部通常是高成本部門，沒有商業價值產出，從企業角度看這是個挺嚴重的問題；如果技術中臺趨於穩定以後，能夠將這些技術精英投入到各個業務部門中將會是一個很好解決方案。讓他們去基層培訓公司的初/中級工程師，將技術中臺的思想傳播給他們，從而提升人才梯隊的技術能力和思想水平。
2.2 中臺的定義
對中臺的定義主要集中在2個流派上：業務流派和技術流派。業務流派認爲中颱其實是一套思想，只要能夠實現能力的複用，降本企業成本，提升交付效率；所採取的一切措施都是中臺的範疇。所以從這種觀點出發中臺更偏重爲一種組織方式，企業內部複用的是彼此之間的能力。由此衍生出來的中臺框架以多語言與多架構共存型中臺爲主。技術流派認爲中颱一定要有核心框架來支撐，需要定義一套技術規範和通用的核心底層框架，事業部之間使用同一套技術框架，而核心底層框架由架構師組成的架構部來維護和迭代；通用底層約束着業務組件的行爲，性能、穩定性和擴展性對業務開發者隱藏，業務部門只關心自己的業務即可，不用參與到費神耗時的“研究性”開發中去。由此衍生出來的中臺框架以多統一架構型中臺爲主。
2.2.1 多語言與多架構共存型中臺
業務流派所認同的中臺形式。這種情況多存在於系統比較多的公司，系統之間架構也不同，語言也各異：SSH、SpringMVC、Spring-boot、Dubbo、PHP和.Net等等。公司通常在一段時間內經歷了快速成長，對於技術架構和底層代碼沒有夯實的積累，技術部門急於完成開發任務，從而催生的一種現象。好處和優點是企業可以快速完成中臺的建設任務；但缺點更多：
- 內部系統的調用方式以Http接口的形式爲主，效率低。
- 框架之間不通用，沒有形成統一的技術體系，缺少統一的約定與規範，導致開發人員學習成本變高，中臺的可維護性低。
- 各個子系統之間的項目性能無法保障，導致中臺整體性能受限。
- 錯誤排查困難，溝通鏈過長，項目開發週期會更長；同時會消耗開發人員更多的精力，開發團隊穩定性也會下降。
- 技術棧過多、不統一，導致運維層面更加複雜；互聯網公司到最後基本拼的都是運維能力強弱。
這方式來推進企業中臺化速度是最快的，但治標不治本，沒有從根本上解決企業存在的問題。
2.2.2 統一架構型中臺
技術流派所認同的中臺形式。這種情況多存在於技術積累夯實、研發預算充足的中大型公司。比如阿里，中臺化歷時三年之久，其內部開發標準、約定、技術都是統一的；阿里的中臺化戰略十分宏偉，但一般公司根本模仿不來，即便像騰訊這樣的公司，中臺化也沒有這麼徹底。我很佩服阿里，非常厲害，又一次爲行業設立的標準。
由於統一架構型中臺的特點是成體系、成建制的，那麼在【多語言多架構共存型中臺】中所暴露出來的問題基本都不存在；可是他也有自己的弊端：技術成本太高，人力資源成本也太高。隨着項目的展開，如果沒有充分的準備，項目風險會越來越大。阿里雖然樹立了行業標杆，但盲目模仿阿里的中臺策略是不可行的；要知道阿里每年在技術上的投入都是以“億”來衡量，很多公司每年的利潤都沒有達到千萬級。那我們應該如何去做？
2.2.3 技術中臺與業務中臺分離
這是我在項目中的一點體會，核心想法也是圍繞着【統一架構型中臺】來實現的；在阿里的中臺思想上退一步，因爲他們的做法對於99.99%公司來講偏“激進”，中小型企業無法承受，即便大一些的二線互聯網公司也很難招架得住。我的思路是這樣的：服務治理使用Dubbo來做，消息隊列使用RocketMq，一級緩存用Ehcache，二級緩存使用Redis集羣，數據庫使用Mycat+MySQL，Api(https網關)出口使用SpringMvc。Web項目作爲服務的組合層來聚合用到的Dubbo Rpc服務，然後統一對外提供API接口。在項目中無論是Dubbo項目還是Web項目，他們都共同依託於同一個核心底層項目，而且項目中的Spring配置文件都會被剝離到核心底層項目中統一維護和管理。讓【核心底層項目】形成一個有通用性和無關性的【技術中臺】；所有業務中臺的項目均依託於技術中臺，在底層架構之上集成開發能力。
打個比方：技術中臺就像土壤，業務中臺就像農作物；技術中臺爲土壤提供什麼樣的肥料、什麼時候澆水自己來決定，只保證農作物能夠健康、快速的成長即可。業務中臺只關心種哪種植物，種玉米掙錢多你就選玉米，種人參掙錢多你就選人蔘。如果今年種玉米賠錢了，那麼OK馬上把所有的玉米都砍掉，我們種人參；但是土壤還是以前的土壤，還能繼續複用。映射到實際的項目開發中，我們只是去掉了不賺錢的業務模塊，而技術含量更高的核心引擎沒有變化。
經過【技術中臺】的高度抽象和封裝以後，所有依託於他的業務項目就變成了最簡單的增刪改查，最多再加個緩存設置和消息隊列，這些活兒剛畢業的大學生都能做。讓業務開發人員更加專注於業務代碼，減少難度較高的研究性開發，這麼做在實際項目開發中能夠大幅度的提升開發效率，減少交付時間，同時系統的整體性能和穩定性也更有保障；公司中的2個項目是這麼做的，親測有效。隨着業務中臺的分離，項目整體的可控性也會提高很多；技術中臺的剝離意味着對項目進行了一次有效的減負，優化了資源配置，同時也能有效降低人員成本。
3 中臺架構如何落地
3.1 系統架構設計
很多公司都在內部推中臺的事情，我們的落地方式僅供參考：
依託技術中臺，提供了API的統一入口項目、基於Quartz二次封裝的分佈式定時任務、服務節點路由、服務降級、分佈式消息隊列、分佈式事物(seata目前尚不穩定，還需要繼續跟進)、多級緩存、統一的權限賬號體系、核心底層matrix-core和開發控制檯：矩陣分佈式管理系統(leader)。matrix-distributed-framework是我們的技術中臺，譯爲矩陣分佈式框架；這個名字是根據哥德爾命題來的：在任何矩陣系統中，總有真理遊離於邏輯之外。之所以這樣說是因爲一個系統也好、平臺也好無論設計的多麼完美(至少在你看來)，他都會有自己的缺陷和漏洞。
Matrix提供的各個模塊都是一個個以maven來管理的子項目，使用的時候他們會被編譯成文Jar包發佈到私服上，供各個業務項目來使用，Dubbo服務或Web項目再通過Jenkins來進行構建和發佈項目。這些高度抽象的模塊，強有力的封裝了他們本身的功能域，項目中所遇到的絕大多數情況都會被考慮到。比如一個基於Tomcat容器的Web項目如果想對外提供統一的API接口，那麼直接引入matrix-api項目的maven座標到pom中即可實現，你不用關心鑑權、驗籤；再比如你想讓這個項目提供定時任務的能力，那麼你只需要引入matrix-quartz即可，至於分佈式定時任務如何實現、分佈式鎖什麼時候加都不需要業務開發者關心，你只需要實現一個抽象類：RootJob.java，然後在固定的方法中寫增刪改查，完成後在矩陣控制檯中加入你的定時任務，配置好觸發規則。
matrix-core是一個最核心的模塊，他剝離了每個項目中的Spring配置文件；也就是說在Matrix的框架體系內，Dubbo項目和Web項目都是沒有applicationContext.xml配置文件的。這樣的設計爲項目提供了極高的靈活性，如果私有化則所有的Dubbo服務編譯成jar包放入到Web項目中形成單體應用；如果微服務化，則正常部署即可。
在技術中臺之上，是基於Dubbo的服務中心。服務依據業務和功能來進行劃分，他們都有各自明確的職能邊界；他和服務組合層共同組成了業務中臺。Dubbo的服務組合會在Web層來進行，儘量避免Dubbo服務相互間的調用。技術中臺會爲業務中臺提供統一的權限控制、日誌管理和分佈式事物控制功能。
3.2 架構細節分解
3.2.1 微服務選擇
在服務治理框架上，我們選擇了Dubbo。原因有如下幾個：
- 久經考驗的阿里戰士，爲電商而生，無論從性能還是穩定性上都是有目共睹的，能夠抗住淘寶的超高流量。
- 版本穩定。Spring-Cloud雖然是新貴，但是版本迭代過快，並不穩定；在項目開發中是大忌。
- 中文文檔齊全，研究的人也多，社區活躍。
- 與Spring無縫融合，只要寫過SSH、SpringMvc的人都可以通過簡單培訓快速入手項目。Spring-Cloud學習成本高。
- 基於Rpc協議的調用比Spring-Cloud提供的Http協議調用少了3次握手，消息傳輸效率更高。
3.2.2 Matrix職能介紹
Matrix的最初目標是積累和沉澱，致力於打造一個企業自己的核心底層框架。從架構圖中可以看出每一個Dubbo服務項目都依賴於Matrix所提供的基礎能力，向上支持業務開發，向下則打通每一個孤島連接。矩陣分佈式管理系統(leader)負責提供一個Web視圖，用於管理核心配置項，形成最基礎的技術中臺。下面將介紹每一個子項目的職能。
上圖是Matrix整體項目結構，下面會將最重要的子項目逐一介紹。
項目地址：https://github.com/PowerYangcl/matrix-distributed-framework.git
1 Leader
針對matrix-admin項目的升級版。Leader使用付費的Layui作爲新的頁面框架，相比之前簡陋的Jsp頁面封裝更加友好。Layui版本爲2.5.3，在其基礎上對table.js進行了少量修改。其餘功能與matrix-admin完全一致。
2 matrix-core
分佈式系統的核心底層項目，提供大量基礎工具與腳手架支持，所有衍生子項目、業務項目都需要在POM中集成這個Jar包。他剝離了applicationContext.xml讓每一個業務項目形成一個殼子，Dubbo項目和Web項目共同使用這個配置文件。Web項目則需要再加入額外的配置文件：spring-mvc.xml，這個文件專門在applicationContext.xml基礎上增加了Controller層的配置
3 matrix-cache
系統緩存封裝，一個系統性能是否強大，通常要看其在業務代碼中緩存使用的佔比和如何使用消息隊列。此項目提供Servlet Context、Ehcache和Redis三種緩存模式，Matrix系統使用Ehcache作爲系統一級緩存，Redis作爲系統二級緩存，Mycat做數據庫分庫中間件。系統一級緩存的讀寫效率是二級緩存的上萬倍，但缺點是需要項目經驗豐富、技術能力強的人才能在具體業務場景中使用。由於是分佈式系統，故對Ehcache不瞭解的人請先詳細瞭解他的使用方法，以免出現大的差錯。
DcacheEnum.java定義了數據字典相關枚舉信息，ScacheEnum.java定義了業務字典相關枚舉信息。CacheLaunch.java是整個緩存的入口類。DistributeLockRedis.java提供基於Redis的高性能分佈式鎖，DistributeLockZk.java提供基於Zookeeper的高可靠分佈式鎖，這兩種鎖可以根據具體的業務場景，自由選擇。
緩存底層把數據庫查詢、拼接數據的業務的代碼統一歸納到一個具體的處理類中，這麼做的好處是查庫放到緩存的這個過程，只有一個入口，業務開發人員不必擔心會有多個地方存在同一個緩存的獲取行爲，以架構約束的方式，將與業務代碼無關的緩存獲取操作從Spring的Service層中分離出來，單獨保存，最大限度的減少因爲遺忘、疏漏而產生的緩存不同的問題。同時，此方法做了防穿透處理，如果一個緩存Key在10分鐘內嘗試20次連續的數據庫查詢操作，那麼將會在10分鐘內連續返回空字符串；也就是說業務開發人員無需在實際業務開發中再考慮緩存穿透的問題。
如下代碼段展示了一個簡單的緩存未在Redis中命中，從而去數據庫中查詢數據、拼裝JSON串兒的過程：
4 matrix-permissions
對matrix-manager的升級項目，此處提供了統一的系統權限。在Matrix體系內，權限被高度抽象和剝離；開發者從Leader系統中錄入每一個系統的功能點和權限，然後在分配給對應平臺的超級管理員；Leader中維護了所有的子平臺權限和功能。這裏體現了矩陣框架“統一”的想法。
5 matrix-api
平臺內置的API網關項目。所有基於Tomcat的容器型項目，在POM中加載這個Jar包後，都具有API接口提供能力。API項目採用MD5加密的方式進行驗籤，矩陣系統會對請求者提供對應的公鑰和私鑰。一個完整的接口請求數據結構如下：
target：api標識符 accessToken：登錄後的令牌，過期時間半小時 client：3代表客戶端，固定值 version：版本號，vsesion-2.0.0.1，固定值 requestTime：本次請求發起時間，md5加密依據之一 channel：渠道，固定值 key：公鑰，由Leader平臺系統進行分配 私鑰：此處不體現，由系統分配給對應客戶端的請求者。 value：md5加密後的結果。 data：請求所攜帶的參數，其中platform爲固定值，每個平臺對應的值不同，由數商管理平臺統一分發。
在系統設計中，所有的API信息均以緩存的方式存在於Redis中，每一個接口都可以針對指定的域名進行跨域操作，接口間的跨域問題由底層統一解決，不用開發者處理。完整的API JSON結構信息如下：
6 matrix-file
文件操作。這個項目中提供了操作文件的接口，當一個Tomcat項目在POM中引入此Jar包後，他即可成爲一個簡單的單點文件服務器。
7 matrix-quartz
爲分佈式定時任務提供支持。基於Quartz，系統對其再次進行了高度封裝，使得開發人員可以輕而易舉的完成定時任務的開發工作。在矩陣後臺，有非常人性化的界面來配置、修改、查看和關閉你想要操作的定時任務。
系統將定時任務的併發控制放到了底層，不需要業務開發人員干預。當一個定時任務執行完成後，通過配置還可以順序性的觸發另一個定時任務。定時任務可以配置是否記錄日誌，如果記錄則可以查看定時任務的執行情況。定時任務分組功能，可以讓定時任務在指定的服務器上執行，每個分組對應一個或幾個服務器的IP地址。定時任務項目：matrix-quartz可以配置在基於Tomcat的web項目中，也可以配置在Dubbo服務中，注意：無需在Spring配置文件中添加任何xml配置，後臺界面全部都能幫你搞定。下面將展示相對應的功能截圖：
8 matrix-route
分佈式節點路由。系統高級功能，他能讓矩陣系統擁有控制所有基於Matrix底層的服務節點的能力。在Matrix體系內，Web項目和Dubbo服務項目都會以生產者的方式註冊到ZK上，Leader可以監控和操作每一個節點的行爲。
9 matrix-rocket-mq
基於rocket-mq進行了二次包裝，提供了生產者和消費者的基礎類。項目開發時只需要引入maven座標即可。