随着中台化概念的推出，這兩年中台變得如火如荼。互聯網公司幾乎人人都在談論各種中台，什麼用戶、搜索、推薦、營銷、支付中台等等。似乎哪家公司不做中台都不好意思了。原來我們說前端(Client/Browser)，後台(Backend)，現在又蹦出一個中台來，而這個中台是為前端的後台服務的。

那麼究竟什麼才是中台呢？衆說紛纭，莫衷一是。一般來講就是指搭建一個面向衆多個上層業務的公共服務模塊，以達到提升開發效率和功能複用的目的。而相比之前的SOA服務化，中台做了一些整合與隔離，面向特定的領域提供各種獨立的子服務，并增加了統一網關，再将各子服務加工為整套的解決方案。

中台技術架構一般都是基于微服務(Microservice)架構體系的。微服務相對單體（Monolithic）架構下的大型應用來講，主要是将各種服務輕量化和微型化、獨立化。微服務會把各種模塊都獨立為一個微型的子應用，各應用之間相互隔離，通過接口和消息來進行通信和驅動。

這樣做的好處就是，各子服務都是獨立的，一個服務出問題不會影響到全部，而且因為服務都比較小，在開發、部署、升級都變得簡單和靈活。這是一種典型的松耦合、去中心化架構。我們知道單個系統如果過于龐大，就會變得臃腫，漸漸失去活力，而微服務則不然，各自獨立自治，把自己做好做強，整體就會有更強大的生命力。當然微服務也有缺點，就是帶來了無數小系統的管理與運維問題，以及各服務之間因為獨立而導緻的開發冗餘。微服務一般會遵循AKF 可擴展立方（Scalability Cube）原則，中台架構設計也一樣，否則随着微服務的龐雜也會變得臃腫不堪。

中台一般都是基于微服務技術架構，但是與一般的微服務不一樣的是，中台并不會直接面向客戶端，而是通過能力輸出，賦能上層業務，即供前台來調用。這時候處理好各種調用方與中台服務之間的關系就變得非常重要，否則就會出現錯亂和錯用的情況。為了解決業務方與中台之間的調用關系，就需要設計一套完善的調用授權機制，讓各應用方既能享受到公共服務的便利，又與其他各方互不幹涉，做到安全可靠。

業務方要想接入中台，需要以開發者身份來創建賬戶，申請權限後，再進行相關調用。

整個過程如下：

1、業務方先申請賬戶和角色

2、再分配開發者token以及配置相應接口和資源權限

3、再挂載某個服務流程套餐(服務流程來自服務與接口的編排)，調用接口時可以傳遞套餐方案

4、再就是根據API文檔進行調用

在鑒權這塊，我們設計了一個中台鑒權服務。一般的中台服務，并不太需要這個鑒權服務體系，一般隻需要網關層面的token鑒權即可，但是對于複雜的中台架構體系，就有必要專門設計一套鑒權服務了，對于API以及資源進行統一的管理授權。

這裡的鑒權服務之所以需要增加資源鑒權，是因為某個資源可能為多個業務方共享，我們需要根據授權配置來确定調用關系。

授權與調用過程如下：

首先，給開發者token配置api訪問權限，以及配置api的資源操作權限，比如依據資源的重要屬性、業務屬性進行授權。

其次，調用方在訪問api接口時，網關根據權限配置确定是否具備某個api的訪問權限。

最後，中台服務根據權限配置，實時計算資源屬性與權限關系，确定這次調用是否合法。

經過以上的中台資源配置，再加上中台鑒權服務設計，我們基本上解決了中台接口鑒權和資源鑒權的問題，達到了按需操作數據資源的目的，有效保障了數據安全。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!