編者按：J2EE異軍突起之時，那些2層架構（web+後端）的人必定是崩潰的；而後spring以without ejb革命了，現在spring已漸成全家桶之勢。SOA概念興起之時，ESB相關的廠商大賺，而今老馬又攜微服務而來，受益者包括企業軟件廠商，各雲平臺廠商等，眼花繚亂漸迷眼，各領風騷好幾年！多點生活架構師陳澤洪本着【少談些概念、多解決問題】的原則給我們分享他們用幾個月完成的這一套分佈式服務框架。近期中生代社羣由ppmoney敖小劍同學分享的微服務架構非常乾貨，幾近跨省追殺；本文同樣是這樣的乾貨，很乾...
選擇開源產品的時候，需要根據自己的實際情況，做必要的改造才能打造出真正適合自己的產品。多點生活通過一系列的減法和加法，打造出了自己的分佈式服務化平臺。
背景
多點生活成立於2015年初，1億美元天使輪，和物美超市深度合作，目標是打造線上線下一體化的全渠道零售平臺。技術研發團隊基本上全 在成都，在成都JAVA好招人，所以基本上在多點內部就是JAVA一統天下了，也沒有去考慮其他的語言了。10幾個人，2個月時間，上線了第一版的業務系統，麻雀雖小五臟俱全，從APP到H5，從商品到購物車，從訂單到交易，從會員到配送履約，十幾個系統。爲了快速開發，全部基於REST API，通過一個叫API Center的中心服務進行中轉服務調用。
圖1、早期的API
Center
隨着業務量的增長，3個月時間用戶量就超過200萬，業務系統不斷增加，服務之間的調用變得越來越複雜，沒有誰能完全理清楚服務之間的關係了。同時APICenter慢慢成爲瓶頸，也佔用了我們不少服務器資源，作爲創業公司，還是要精打細算的。而且APICenter作爲服務中心路由節點，所有的服務調用都走這裏通過。有一次，我們的一個工程師出了一個bug，在一個死循環中不停調用某個服務，直接把APICenter搞掛了，所有服務都不能提供服務，只能簡單粗暴重啓服務或幹掉問題服務。
圖2、業務發展一年後的全景圖
創業公司，時間寶貴，拿來主義
爲了解決上面的問題，迫切要有一套分佈式服務框架來解決這些問題，由於時間緊，人手有限，從頭開發一個肯定是來不及了。所以我們本着拿來主義的原則選擇了一個開源的框架來用，那就是dubbo。雖然dubbo並不是市面上最好、最新的服務框架，但是我們很多人對dubbo都很熟悉，使用成本低，於是就選擇了它，本身我們只需要支持JAVA語言就夠了。
先做減法，再做加法
dubbo相對來說是一個很老的框架了，功能很龐雜，有很多我們用不上的東西，同時有很多我們想要的功能卻沒有。於是我們第一步先做減法：精簡內核，去掉所有不要的功能，幹掉了差不多一半的功能；第二步：調整策略，修改測試發現的bug；第三步：添加我們必要的功能。2個人，1個月時間，就基本上改造完成了符合我們預期的分佈式服務化框架。
圖3、多點服務化框架DSF
核心功能點：
1、RPC
[保持不變]
這塊基本上沒有做什麼調整，直接沿用dubbo基於netty的長連接的傳輸，hessian的序列化，在滿足我們的業務調用量的前提下，不引入更多的依賴，保持簡單就好。
2、服務註冊和發現 [改進]
我們是基於Zookeeper來做服務註冊與發現，也沒有什麼大的問題，而且幾乎是現成的解決方案，不需要開發什麼代碼。隨着我們開始多機房（混合雲）部署，就創建了一個大的ZK集羣，不同機房的應用優先連本地的ZK節點，優先調用本地機房的服務，當本地機房的服務不可用的時候，自動跨專線調用另外機房的服務。
這些功能本身dubbo並沒有提供，需要我們代碼來實現。但是由此帶來了不少的運維複雜度，我們需要針對不同機房的應用部署打包配置不同的參數，以適應優先本地機房配置。於是我們就開發了我們自己的配置中心(Admiral)，可以用同一個打包部署文件，自動適配不同機房不同的參數來達到本地機房優先的原則。
圖4、優先註冊和調用本地服務
圖5、基於配置中心，自動獲取配置參數
3、監控與報警 [新增]
監控對於一個系統來說是就像人的耳目，不可或缺。我們就在框架層無侵入的採集服務調用的關鍵指標：調用次數、響應時間、錯誤率等，然後基於開源的監控系統open-falcon來存儲監控數據，通過內部的DMC報警平臺通知應用負責人。對於監控數據，我們還從兩個維度去監控數據：服務提供方維度，服務使用方維度。這樣我們就可以在監控數據報警時，發現是哪一方出現問題了。比如，調用方發現響應時間很高，但是服務提供方的響應時間很低，那麼問題就出在服務調用方或提供方到調用方的網絡有問題。
圖6、基於Open-falcon的服務調用監控
4、服務依賴管理 [新增]
作爲分佈式服務平臺，我們迫切需要知道服務的部署情況，服務的依賴情況，需要很直觀的查看和搜索。這樣就能清楚明白服務的調用關係，在升級服務之前可以一鍵郵件通知依賴方。同時還可以通過不同維度查看服務依賴：服務提供方視角、服務使用方視角、應用視角、服務視角、機器視角，以滿足不同場景的需求。
圖7、可視化的服務依賴關係
圖8、服務依賴的明細
5、鑑權控制 [新增]：
很多時候有些服務是不希望別人隨意調用的，就需要增加鑑權管理。dubbo本身只提供服務註冊層面的管理，沒有提供服務級別的健全管理。我們就在框架層統一增加了鑑權token支持，通過簡單的xml配置，只有提供了鑑權token key的調用方纔能正常調用，否則會被拒絕。
6、動態配置 [改進]：
有時候業務需要在不重啓服務的情況下動態調整參數，比如：權重、超時時間等。dubbo原生的動態配置很簡陋，幾乎不太可能直接拿到生產環境使用。於是我們做了不少改進，在web頁面上可視化動態調整參數，還可以指定參數生效的scope：服務提供方，服務調用方，全局配置，單一實例配置，應用級別，服務級別等，極大方便了線上發佈調整。
圖9、在線動態參數調整
7、在線驗證 [新增]：
因爲我們用的是基於二進制協議的RPC調用，要想像rest api一樣用postman之類的工具簡單方便地無client調用驗證服務API，其實是很麻煩的。爲了解決有些純後臺的服務發佈上線驗證，我們就增加了在線驗證功能，通過泛化調用，無需寫調用方代碼，直接在線可視化調用服務進行驗證，極大地方便了研發測試驗證。
圖10、在線服務驗證
8、調用鏈跟蹤 [待實現]：
作爲分佈式系統，服務的調用鏈跟蹤對於問題的排查是非常有幫助的，鑑於開發人手不足，我們暫時沒有提供這個功能，後續計劃整合pinpoint，提供完善的調用鏈跟蹤。
總結
通過這一系列的減法和加法，很快就打造出了多點生活自己的分佈式服務化平臺，其實市面上很多的服務化框架只提供了基本的RPC調用和服務註冊，對於服務治理和監控，以及動態管理和鑑權控制幾乎很少有開源的。在大家選擇開源產品的時候，需要根據自己的實際情況，做必要的改造才能打造出真正適合自己的產品。