本文章通過玩事創新應用的發展之路，來介紹如何隨著業務的不斷發展抽象出的業務中臺。
玩事，不一樣的做事方式。這是乙個17年3月初開始創新孵化17年4月1日上線的創新產品。經過1年多的發展，從最簡單的發榮耀功能，發展至今包含榮耀、榮譽、祝福、權益中心、金豆雨、學一下、猜一下、權益雨等多種創新互動的場景，並形成以基礎資料、金豆、標籤、權益為核心的中颱微服務。下面談談玩事是如何基於iuap的paas平台快速構建業務，逐步抽象出核心的中颱微服務。網際網路界一直都在呼喊「大中台，小前台」的理念，但到底什麼是中颱呢？下面是iuap對中颱的乙個理解：
中颱更多是一種理念，
大家以中颱的方式思考和行動，
業務發展是核心目標，中臺能力沉澱是持續保障！
中臺不是簡單的產品或者平台，
她代表著全新的：
業務服務模式+架構模式+組織協作模式
圖1 - 玩事中颱架構圖
圖2 - 玩事技術架構圖
玩事建立新應用是基於iuap的 gpaas、bpaas、dpaas平台快速建立的。gpaas平台提供了開發運維一體化及基礎的技術支撐，bpaas提供了使用者、員工、專案、企業賬號、團隊、訊息等基礎服務的支撐，dpaas提供了資料收集、資料包表的基礎支撐。在這些強大的paas平台技術的支援下，才有玩事的專注於業務創新。
上線之初，玩事就初步具備了金豆、榮耀和權益三個應用，只是初期的功能非常簡單。隨著業務的不斷發展，增加了很多的新業務：榮譽、祝福、拍磚、學一下、猜一下、投一下、權益券等。如果不對應用進一步的抽象出中臺業務的話，業務中可能會存在大量的重複邏輯，非常不利於維護和未來的持續發展。以標籤核心微服務的抽取過程來闡述下如何抽象業務中颱微服務。下面是最初的發榮耀業務流程圖：
圖3 - 榮耀發放流程圖
隨著業務的不斷發展，新增了發拍磚、發祝福、發榮譽以及扣減庫存發榮耀等需求，他們的大致業務流程相同，卻存在一些細微的差別。如果進行抽象，那麼榮耀、拍磚、祝福、榮譽存在將會存在大量的重複業務邏輯和**，浪費開發資源也不利於長遠的發展。
圖4 - 榮耀、拍磚、祝福、榮譽發放流程圖
仔細觀察我們會發現，榮耀、拍磚、祝福、榮譽存在一些共同的特性，他們實際上本身都是乙個標籤資訊，區別在於榮耀、祝福、榮譽是轉賬金豆，拍磚是扣減金豆，榮耀支援用庫存發放，祝福支援發權益券。為此我們抽象出乙個標籤的中颱微服務。
圖5 - 標籤抽象圖
當然標籤微服務的能力和擴充套件點除了標籤的業務操作外，還有校驗、報錯、im訊息等都可能存在細微的差別，都可以通過擴充套件的這種方式來完成對主題業務的抽象統一，細微差別的個性化操作。這樣的好處在於，如果後續發榮耀的業務也要支援送權益券僅需要改個配置引數就可以了，不需要重複開發。抽象出業務中臺服務後，可以將這些服務重新反補到bpaas平台，提供給更多的應用使用這些能力，並逐步發展和壯大這些核心微服務。
在實際的中颱核心微服務抽取過程遠比這複雜，但是要抓住業務核心，針對ddd領域建模，抽象出領域服務的核心能力，差別的操作通過擴充套件的方式來實現。只要抓住這些核心方法，相信一定可以抽象出合理的中颱服務。
中臺構建日誌
一 kong作為服務管理中心底層平台 啟用 統一認證外掛程式 啟用 統一會話外掛程式 繫結所有應用的login路由，在返回登入響應時候，統一儲存使用者資訊到redis快取，快取的key取token值 對服務的請求，早於認證外掛程式，先按照token檢查會話是否已經在，如果已經存在就繞過認證外掛程式，...
業務中臺經驗分享
業務中臺重構 業務有 影像 saas及口腔 鏈三大業務板塊 我們這邊主要負責的業務有診所sass系統,經銷商 自營 erp,wms 分公司的 等系統 之前的童鞋基於soa 的架構做了乙個版本，但是 還是有很多問題及一些核心服務語言差異，開發 框架沒統一，業務流程不清晰，devops 流程 不統一 等...
業務中臺建設與應用 資料中臺建設是氣象業務的基石
早就想聊聊這個話題，感覺說多重要都不過分！按理說我們氣象部門的資料儲存 處理和應用相比其他行業具有先天優勢，無論觀測還是預報，每天能夠產生海量資料，並且有規範的資料格式和先進的資料儲存裝置。可這麼多的資料，大都是死資料，並沒 有充分用起來，或者利用率很低，根本沒有發揮出氣象大資料的應有價值。我覺得之...