基於Kebernetes 構建.NET Core技術中臺

原文: 基於Kebernetes 構建.NET Core技術中臺

咱們爲何須要中臺

咱們如今處於企業信息化的新時代。爲何這樣說呢？

過去企業信息化的主流重心是企業內部信息化。但如今以及將來的企業信息化的主流重心是企業外部信息化。

中國互聯網從1998年算起（新浪搜狐網易都在那一年成立），到如今過去了20年。在這20年裏，也就兩個階段。按to C的分法就是PC互聯網時代、移動互聯網時代，按to B的分法營銷時代、交易時代。第一個10年（1998-2008），無論你是搞音樂圖片視頻，仍是你搞新聞、爬蟲新聞、博客論壇，本質上就一個事：作內容拉消費者流量而後拉企業廣告變現。到了第二個10年（2008-2018），給企業倒流量，企業已經不信了，你給我多少點擊量沒用，我歸根到底仍是得看我賣出了多少東西。因此中國互聯網進入了交易時代。從2008年以後，中國電子商務公司如雨後春筍爆發，就是由於這個歷史大規律背景。從如今開始到將來十年（2018-2028），進入了第三個時代。由於在第二個十年，有了消費者也有了訂單了，可是上游生產、採購、研發設計不給力啊。市場機會轉瞬即逝，誰快誰就能抓住機會。因此上游生產、採購、研發設計必需要變革，來適應下游消費者訂單。這就是中國互聯網企業紛紛進入to B市場紛紛進入企業服務領域的根本歷史大背景。

中國企業軟件，從內部單部門單崗位應用，進化到內部多部門多崗位應用，後來又到整個企業乃至整個企業集團的所有應用。再往大長，就必需要突破企業邊界，進化到企業的衣食父母（客戶）的信息化，這就是我說的鏈接客戶（消費者），讓消費者直接參與到企業IT業務流程處理中。進而再進化到鏈接企業的上下游，爲消費者需求與訂單進行通力合做、敏捷互動。最後再進化到鏈接社會基礎設施，如工商稅務海關銀行、交管車管、國土住建、社保民政、質檢安監...。

如今以及將來的企業信息化的主流重心是企業外部信息化：鏈接消費者、鏈接產供銷研上下游、鏈接社會基礎設施單位。由於要鏈接消費者。也就是說，消費者在哪裏，咱們就要鏈接哪裏。這勢必形成了IT應用微型化、場景化、碎片化。尤爲如今是移動互聯網時代，App技術特性決定了流量是被碎片化的不能聚合的。

中國的消費者是巨量的。中國每個省就至關於歐洲的一個國家的大小、GDP規模、人口數量。咱們必須把咱們過去鐵板一塊的應用拆分拆分。與外部鏈接相關的的應用場景，必定要作成微型化、場景化、碎片化、微服務Open API技術，這樣便於快速鏈接、快速迭代改變。

業務中臺

業務中臺，主要就是業務支持，好比統一會員、統一認證、統一營銷、統一訂單、統一庫存、統一支付，這些統一的東西來自一個地方，分別支持多個系統對業務的管理要求，不一樣系統開發的時候，能夠直接從這裏獲取這個功能，而不須要再開發，從而把更多的系統鏈接在一塊兒。 業務中臺使得任何一條業務線都具有整個公司的核心能力。

應用中臺

作商業應用級別的基礎設施，就必須擁有應用中臺，如企業雲盤、音視頻會議、企業直播、IM、多觸點交互機器人、聚合支付、電子發票、電子合同、電子憑證、銀企直聯...，他們都帶有業務應用特徵，不是純技術。可是他們又不是具體的業務場景應用，不是相似零售、製造、人力、財稅、OA、供應鏈、CRM等等。

技術中臺

騰訊組織架構調整中，我印象比較深入的是「騰訊成立技術委員會，經過內部分佈式開源協同，增強基礎研發，打造具備騰訊特點的技術中臺等一系列措施，促成更多協做與創新」。

技術中臺，過去咱們把他們叫作技術平臺。它是企業應用的技術平臺。

爲啥過去叫技術平臺，如今就叫技術中臺了呢？

由於過去技術平臺是恆定的。也就是說，你發佈了一個版本，你用一年它也是這個功能能力，你用十年它也是這個功能能力，功能能力是不變的。 可是，有了數據和AI驅動，這個技術平臺就不恆定了。它裏面的不少功能特性就在每天進化、每天模型、參數在自動調節。因此咱們就把技術平臺升級到了技術中臺的概念層面。

不要把中臺部署到企業內部私有環境中，這是錯誤的方向，這是老舊的技術平臺的思惟。若是部署在企業內部私有環境中，它就接受不到社會360度海量數據的訓練了，它只能接受你這一家企業單點的數據訓練了，因此它就成三歲小孩了，智力不增加了。

若是你部署在公有云或者專屬雲上，就會接受咱們平常360度的數據訓練，它的智力就會每天進化，隨着社會動態變化不斷自動調節適應了。

你能夠把和外部鏈接的應用放到公有云上，由於他們是外部鏈接型的，你把他們放到你的內部私有環境中他們就跑不起來了。

你固然能夠把你只內部的應用放到你的內部私有環境中。要把公有外部鏈接的應用和純內部使用的應用鏈接在一塊兒，這就須要到了技術中臺。按照這個角度來看，中臺也不該該部署在私有環境中啊。它必定要放在混合雲環境中，這樣才方便公有云應用和私有云應用鏈接打通。

在技術中臺這裏，最核心的就是集成中臺：

一、集成各種企業內部ERP

二、集成各種公有云SaaS

三、集成各種互聯網電子商務Open API

四、對外統一開放API，便於外部生態應用接入與融合

你看，大量都是內外鏈接能力，須要常常變更、須要內外通暢。

數據中臺

所謂的數據中臺，是帶有產業主數據、畫像標籤、業務模型、業務算法的。

數據中臺，利用獲取的各種信息、行爲習慣信息和算法，獲取分析結果，好比業務中臺參照的客戶標準和分類方法就是基於數據中臺運算的分析結果，例如需求偏好（客戶標籤）。 數據中臺的數據來自業務系統，有原始數據（不一樣頻次的歷史快照+實時數據）、共享數據（拉到一塊兒）、萃取數據（已經整理的標準化數據、標籤、模型），再反哺給業務中臺用起來。以精準營銷爲例，數據中臺支持算法，業務中臺基於算法的結果，支撐實時推薦。

基於K8s&.NET Core搭建技術中臺

深圳市友浩達科技有限公司根據企業在架構、技術、研發、運營、業務發展等方面的實際需求，打造「容器」+「微服務」+「AI」的創新性解決方案。

友浩達微服務能力中臺基於騰訊雲容器服務TKE 領先的 Docker容器技術和.NET Core 微服務架構方案，以及 AI 引擎和大數據服務能力，爲企業提供了大型應用微服務化運維和管理能力、容器集羣管理、容器部署、服務運維、持續集成、持續部署、租戶隔離、微服務治理、APM 性能管理、AI 模型服務等功能，賦能企業應用敏捷落地，助力企業數字化、智能化轉型。

一、使用TKE 搭建的統一容器 PaaS 平臺，將軟件從底層硬件中解耦，提供更好的可移植性和速度，打造輕量、快速、高效、友好的服務運行及開發環境，極大的下降了運維成本；

二、開發微服務架構應用，實現多個微服務組件能夠獨立部署，經過統一通訊協議互相鏈接，保證獨立性和高可用性，同時簡化了部署、監控、運維、治理與微服務應用生命週期的管理；

三、使用微軟先進成熟的Azure DevOps 產品，從新規劃設計開發測試運維的工做流程，優化開發測試標準的同時將平常繁瑣的重複性工做交由平臺來自動化完成，包括源代碼管理、自動化構建、自動化測試、持續集成、持續部署等，顯著的提升了應用系統的開發迭代效率；

四、基於 Kubernetes 核心支撐能力，實現對於應用服務的灰度發佈、滾動升級、彈性伸縮、故障自愈、配置管理、服務高可用等多種治理手段，提供了統一的企業IT管理平臺，提升了企業IT管理效率；

五、基於.NET Core的高效率開發微服務，高性能運行的微服務系統開發

技術中臺架構以K8S+Docker容器化技術爲基礎構建運行支撐平臺，基於容器化技術的靈活伸縮能力數據集成、服務集成、數據利用、公共服務、DevOps，造成企業級的技術中臺。整體架構圖以下：

服務網關是全部應用系統對外訪問的流量入口，可以實現各個應用的訪問，以及應用之間的相互訪問能力，而且總體提高訪問的安全性，整體訪問過程以下圖：

爲何選擇.NET Core

說到技術棧，腦海中是否是浮現的是這樣一幅圖？

有點眼暈，如下只是咱們會用到的一些語言的合集，並且只是語言層面的一部分，就整個技術棧來講，這只是一個開始，從語言開始，還有不少不少的內容。

整個技術棧個人理解包括 4 個層面的內容：

• 語言： 用了哪些開發語言，如：C++/C#/Java/Go/PHP/Python等等；

• 組件：用了哪些組件，如：消息隊列組件，數據庫組件等等；

• 流程：怎樣的流程和規範，如：開發流程，項目流程，發佈流程，監控告警流程，代碼規範等等；

• 系統：系統化建設，上面的流程須要有系統來保證，如：規範發佈流程的發佈系統，代碼管理系統等等；

在創業公司，沒有大公司那些完善的基礎設施，須要咱們從開源社區，從雲服務商甚至有些須要本身去組合，去拼裝，去開發一個適合本身的組件或系統以達成咱們的目標。

選擇合適的語言

• 選擇團隊熟悉的/能掌控的，創業公司人少事多，無太多冗餘讓研發團隊熟悉新的語言，能快速上手，能快速出活，出了問題能快速解決的問題的語言纔是好的選擇。

• 選擇更現代一些的，這裏的現代是指語言自己已經完成一些以前須要特殊處理的特性，好比內存管理，線程等等。

• 選擇開源輪子多的或者社區活躍度高的，這個原則是爲了保證在開發過程當中減小投入，有穩定可靠的輪子可使用，遇到問題能夠在網上快速搜索到答案。

• 選擇好招人的 一門合適的語言會讓創業團隊減小招聘的成本，快速招到合適的人。

• 選擇能讓人有興趣的 與上面一點相關，讓人感興趣，在後面留人時有用。

選擇合適的組件和雲服務商

• 選擇靠譜的雲服務商；

• 選擇雲服務商的組件；

• 選擇成熟的開源組件，而不是最新出的組件；

• 選擇採用在一線互聯網公司落地而且開源的，且在社區內造成良好口碑的產品；

• 開源社區活躍度；

選擇了雲服務商之後，就會有不少的產品你能夠選擇了，比較存儲，隊列這些都會有現成的產品，這個時候就糾結了，是用呢？仍是本身在雲主機上搭呢？在這裏個人建議是前期先用雲服務商的，大了後再本身搞，這樣會少掉不少運維的事情，可是這裏要多瞭解一下雲服務商的組件特性以及一些坑，好比他們內網會常常斷開，他們升級也會閃斷，因此在業務側要作好容錯和規避。關於開源組件，儘量選擇成熟的，成熟的組件經歷了時間的考驗，基本不會出大的問題，而且有成套的配套工具，出了問題在網上也能夠很快的找到答案，你所遇到的坑基本上都有人踩過了。