2020年，普元基於自身技術中臺所需，驗證了一些新技術並加以使用，旨在不斷提升技術中臺的綜合能力。通過這次機會，將我們團隊所做的一些技術驗證和使用方式與大家分享，希望在公司內外建立更好的技術溝通，同時提出技術中臺的下一步發展想法，供大家參考指正。
1、介紹普元技術中臺的現狀
首先來看看我們現在中臺的一個大概的情況。從下往上看的話，以基礎設施開始，到容器雲&中間件平臺，再往上有兩個平臺，一個是運行&集成平臺，用於支撐微服務、元數據、流程引擎等一系列的基礎架構；另一個是效率&精益的平臺，即DevOps，用於解決自動化測試、持續構建、自動部署等，再往上則根據行業去積累相關的業務組件。從圖上可以看到，現在圈出來的這一部分，就是在普元定位出來的技術中臺的一個全景。
容器雲&中間件平臺，最下面有一層集中式的調度、分發、監控、預警，這個是所有的中間件以及上層的應用需要的一個必備能力，接着也會在容器雲中去建設像緩存消息、隊列、數據庫，NOSQL這一系列。
運行&集成平臺上，我們分了兩塊，一塊是應用，這裏面以微服務作爲支撐，用BPS等做流程集成、用ESB做API集成。再上面是跨端工具。還有一塊是數據，以元數據爲基礎，數據質量稽覈、數據的交換，數據的分析、數據的服務、數據的展示等這一系列數據全生命週期管理。
效率&精益平臺，更多的瞄向從項目立項，需求任務缺陷等這一系列的管理到代碼分支標籤、到持續集成、到自動發佈，再到後續的整體運維。
2、分享2020年新驗證使用的一些技術
2020年的新技術使用，整體上是這樣的：主要分爲三類：框架類、工具類、平臺類。可能大家理解平臺類和框架類好像有點類似，之所以叫平臺類，我們認爲這些東西可能當一個第三方的平臺去參考或者去應用，而不是把它納管到我們自己的內部的一個產品體系。還有一些之所以放在平臺類，是因爲我們更多是做了一些驗證，還沒有跟我們的東西完全集成在一起。分開來看看到底爲什麼要選擇這些，用它來解決什麼問題？
框架類
第一個istio， istio是用於解決在spring cloud架構下，像ribbon、netflix等流量管理，無法去解決其他語言的一些情況。因爲它只面向於spring cloud，對其他架構、語言的系統無法統一管控。如果針對這些系統要去做流量治理時，則需要引入像istio這樣的三方組件，使得我們其實是可以跨系統跨語言形成服務治理。
所謂的服務治理，主要是熔斷、限流、流量的分發、負載均衡等這一系列的需求。istio目前是部署在我們容器雲平臺裏的。
第二個其實是spring cloud的K8s。大家在用spring cloud時，如果同時引入容器雲的時候，往往會有很多的糾結點。比如說所有的服務進程，既註冊在Eureka，或者Nacos上面，同樣在容器雲裏，所有的服務都在ETCD上去註冊了，這個時候我們到底應該以誰爲準？
再一個例子，SpringConfig做配置管理，但是其實在容器雲下有自己的configmap做配置管理，或者說負載均衡ribbon的情況下，到底我們去調用其他的服務的時候，是走k8s service，還是直接調他所有的pods，其實都是大家很糾結的點。
早期我們也很糾結這樣的一些問題，自從spring cloud生態中引入了springcloud K8s這樣的組件，問題則迎刃而解。
現在做到了開發的時候，你不用關心底層基礎設施，然後在打包的時候通過不同的依賴，使得在使用不同的基礎設施的時候，實際運行的介質不一樣，是我們對spring cloud k8s的驗證和使用情況。
第三個是flink。熟悉普元的話，都知道我們更多的在數據這一層做的批數據，從數據集層到貼源層，然後再做標準化，做治理，再到主題庫，打標籤等等，最終支撐數據應用，做數據的服務化或展示。
但是我們對於實時的或者準實時的數據採集加工，校驗計算，發佈訂閱，之前並沒有做太多的支撐。在今年我們做了flink預研，用來幫我們解決流式數據問題，最終流一體，支撐數據全生命週期管控。
工具類
工具類裏首先是neo4j，一種圖數據庫。我們有兩個場景需要使用，第一個是元數據產品，元數據產品最簡單的功能是採集數據庫有多少張表，一個表裏有多少列等，還有這些數據之間的一系列關係，以前我們用傳統的關係數據庫去存儲這樣的關係的，當到了一定數據量的時候，自然這塊就會出現了瓶頸，所以接着我們把元數據中關係信息存儲到了圖數據庫，很大程度解決了性能瓶頸。
第二個場景則是知識圖譜。舉個例子，我們都知道東成西就的演員有梁朝偉、張家輝，我們這個時候如果想知道他倆有合作過其他的什麼電影呢？這個時候就涉及到不是一個簡單的人跟電影的關係了，涉及到多個人跟多部電影的關係，類似於這樣的知識圖譜場景，是我們要用neo4j的另一個場景。
當然使用neo4j也遺留了一些問題，因爲大家知道neo4j的社區版跟商業版是不同的。商業版是收費的，如果用社區版的話,要解決可靠性問題，目前我們只能考慮冷備。另一個neo4j被詬病的批量插入性能問題，因爲這兩個場景並不涉及到海量數據的一次性插入，所以這個不是我們的主要瓶頸。
第二個工具有點雜，或者說不是單個工具，因爲普元以前的話更多的插件是圍繞着Eclipse去做插件開發的，而現在vscode、idea這樣的一些插件成爲了很多人的偏好。
其實在2019年開始到現在2020年，我們已經講很多的插件體系在保留原有的一個eclipse的同時，去做了其他工具的補充。比如在vscode上我們支持了面向於移動類的快速開發插件，idea上我們做了個人工作項查看插件。
再一個工具是k9s，運維的同學可能更熟悉一些，k8s的使用如get pod，get service這樣的一些命令，在k9s上則可以使用類似字符終端模式來交互。
平臺類
平臺類的新技術運營，主要是藉助補強了我們一些解決方案。
第一個是fisco。因爲普元有像數據交換，資源目錄這樣的平臺，在國家一些文件要求下，我們要去回答，什麼樣的數據要上鍊，上什麼鏈（私鏈也有公鏈，也有聯盟鏈）等問題， 所以我們在做一些技術選型和廠商適配。
像百度、京東、華爲像螞蟻，他們都會提供他的一些鏈的服務，假設客戶選擇了這些鏈，或者說聯盟鏈，我們也會去把我們的產品去做兼容性適配。我們目前在fisco這一層，其實主要是瞄向於政務口的，金融口上我們其實並沒有做太多的應用。
第二塊是datax，我們其實並沒有用datax，之所以研究datax，是因爲我們有一個跟datax類似的一個產品——DI（基於kettle）。kettle是一個優秀的etl工具，但是擴展的時候，其實會有一些難度。參照datax對於writer和reader的擴展，我們致力於讓DI的擴展更簡單。
再一個其實是性能的問題，我們關注了datax性能到底怎麼樣，比如數據在交換的時候，嘗試分批去做，這個在kettle也做得到，但是我們之前並沒有把這個做成標準化的模板，這是我們在學習datax的思路後，重點想解決的一些問題。
最後一個code-server，code-server是我們最初看的一個在線開發平臺，支持在線去寫代碼，我們是想和自己的DevOps產品無縫集成，解決開發階段的環境準備等問題。
code-server很像VScode的在線版，但是我們後面覺得寫個腳本還可以，寫真正的像JAVA、Python這樣語言的時候，還是不太好用，包括代碼提示，着色，重構等。
現在我們還在關注另一個在線開發平臺Theia，目前來講體驗上相對比較好，包括像Java代碼的支持，後面我們可能更傾向於用Theia作爲我們的一個解決方案。
3、提出2021年技術中臺的發展想法
作爲一個技術中臺，其實前面內容描述了我們既有容器雲和中間件，也有微服務，流程，服務集成，元數據，數據集成等等，我們下一步想法是這樣的：
第一塊：我們想把所有的普元產品都放到容器雲上來，現在的想法是通過helm來做，形成可完全自動部署的模板，包括我們的運行&集成的平臺、效率&精益的平臺，都會作爲一個個平臺組件來做,是第一步要做的事。
第二塊要做的事是把我們的效率&工程平臺去放大。以前更多的是自動發打包和發佈應用與數據，後續我們會考慮支持更多的部署物，比如三方中間件，spark作業等等。
第三塊則相對散一點，舉一些例子吧：效率&精益平臺會去做統一的任務中心，同時補充一些角色的日常關注點，比如像PMO視角的一些報表。運行&集成平臺，會將治理門戶持續增強，形成跨系統的監控運維。數據交換髮布場景，準備按以往實施經驗，去做一個相對易用的數據實施工具。
