整個計劃主要分為三個部分：
▍1. 以業務開發為核心驅動的技術棧中間件設計與實現。
這部分主要以Java語言開發為主，主要講述以Java語言為主開發的技術棧Albianj與任務
調度系統Scher與Jinwei系統。Albianj是一個類似于spring+hbm的高性能擴展版。類比spring與hbm，IOC、DI響應的做了簡單化處理，但是增強了對于數據庫分庫分表的數據路由功能、分布式事務的控制功能等一序列面對海量數據與互聯網快速開發要求的實現。整個albianj不僅僅只有spring與hbm的功能，它更是我們業務開發的核心，整個架構圖如下
Scher與Jinwei是我們任務調度的兩個不同類型的區分。他們分別完成定時和實時任務的調度。
它們基于Albianj實現，有著相同的物理與邏輯架構，并且有著90%重疊的功能，但是我們卻在設計、開發與部署的時候進行了強制性的隔離，這里的原因痛苦而無奈，想知道為什么嗎？來，我告訴你。
▍ 2. 高性能開發為主的中間件設計與實現。這部分主要由linux下的C開發為主，主要講述我們自我實現的分布式id生成器Chaos，分布式文件系統DFS、分布式緩存系統lest與分布式協調器lax，通訊協議hms與使用JNI實現的http服務Aru。分布式id生成器Chaos主要為我們的業務生成全站的、可視化、區間內單調遞增的id，用于取代老舊的MySQL自增id或者是uuid作為主鍵的方案。
Chaos生成的id和albianj的數據路由進行緊密的配合，可以使開發者在無感知、無侵入的情況下快速而有效的開發出可以抵擋億級PV的分布式業務系統。DFS就不用多說了，這是一個互聯網公司走向中間件自主的必經之路，也是標志之一。因為我們業務的特殊性，要求對于DFS存儲的內容可進行頻繁的更改，所以市面上其實并無相應的成熟DFS可用，故我們別無選擇。我們在DFS上花了很大的時間進行設計和優化，使其滿足我們每天億級新增/更改的需求。有了DFS的內容存儲，我們又對其增加了一個出口：這就是我們的Arch系統。說起Arch系統，這僅僅是出于我們自己的看不慣和“2”的精神。因為覺得netty太過復雜，所以就動了自己寫一個精簡NIO的惻隱之心，所以就在“好玩”的驅使下，我們使用JNI自己封裝了一個C版本的NIO，然后因為想試試它的完備性、健壯性和性能，思來想去http簡單，那就搞一個小心的http服務器吧。所以arch由此誕生。目前arch運行在我們的圖片、音頻等項目中，為漫畫、精排、封面提供每天億級訪問的服務。對于圖片、音頻等當然是主要輸出就可以了。但是對于內容就沒有那么簡單了，所以我們在DFS上又增加了一套基于大數據和AI的關鍵字鑒別與分析系統，這樣將DFS完整的平臺化。分布式緩存系統lest和分布式協調器lax則不同，他們的出現來自于我們對于緩存管理的無奈和懊惱，還有對于zookeeper的失望。以前我們的緩存使用了26臺的redis來進行管理，機器數量增加的同時也增加了成本，并且redis客戶端的分布式模式時間長了真的很難管理。所以我們開發了lest，一個不需要大內存而基于ssd的緩存系統。為了給lest增加嚴格的版本控制，實驗了zookeeper，不管是部署還是性能，都不滿足我們的需求和胃口，再者zk的功能太多了，我們又及其討厭開源軟件的“復雜稅”，所以在迫于無奈的情況下，我們只能自己開發了分布式協調器lax。從而將lest和lax組合成一個完整的系統。
又因為lest和lax的存儲與通訊的需要，在研究了google的pb等所謂的通訊協議后，還是不太滿意這些開源的通訊協議不要中間協議文件與編譯的步驟，所以在此基礎上我們構建了hms通訊與存續協議。 并且是hms不僅僅滿足存儲與通訊協議的需求，我們更是將hms的對象作為一個對象樹，還集成了簡單的查詢方法，可以提供簡單的大于，小于，等于等等查詢。▍ 3. 一部分
我們將討論一點哲學問題：人、團隊、架構、業務代碼之間的4角關系。 說了那么多，其實我就是想表達一個觀點：完全自主化中間件并不難。我們一個團隊花了沒多少時間就開發了那么多的東西，雖然中間也碰到了各種的問題，好在都順利的解決了。還是印證了那句話：人類的進程是由算法決定的—尤瓦爾·赫拉利每天的業務開發是不是讓你已經厭倦了整天加班的痛苦？所以，你準備好了嗎？中間件開發這門藝術幾乎就要失傳了，你還不趕快來參加我們？
粵嵌科技13年專注IT人才培訓學習的專業機構,主要培訓課程為,嵌入式開發、Java大數據、Unity游戲開發、Python人工智能、HTML5前端開發、全棧UI設計、網絡營銷、CCIE網絡等專業課程