net的微服務架構

標籤：orm   基於   border   ops   製作   不能   www   單元測試   連網   

net的微服務架構

眼下，做互連網應用，最火的架構是微服務，最熱的研發管理就是DevOps， 沒有之一。微服務、DevOps已經被大量應用，它們已經像傳說中的那樣，可以無所不能。特來電雲平台，通過近兩年多的實踐，發現完全不像大家說的那樣簡單，大家是報喜不報憂，實在是水太深，誰做誰知道。今天就與大家分享一下在微服務架構+DevOps下，開發測試環境的一些營運痛點問題和解決方案。

      架構的複雜度直接決定了營運的工作量，架構不是越複雜越好，而是適合最好。下面簡單說說幾種架構的優缺點。基於.net在搭建應用時，最常用的方法就是採用Asp.net MVC，前端、後端 All in到一個網站中，省時省力，完全不用關心部署營運的複雜度。但是弊端也非常明顯，所有內容部署在一個網站下，如果業務複雜，系統的變化頻率非常高，穩定性堪憂，基本無解。再複雜一些的就是前後端分離：H5（或Winform） + WebAPI，此種架構雖然把前後端的變化分開了，但是後端邏輯缺少複用，存在大量公用方法或者重複代碼。更複雜的就是：前端+WebAPI+Service，這種模式下雖然抽取了公用服務，但是部署粒度還是很粗，基本上會按照業務範圍分多叢集部署。同一個叢集下，部署的服務如果太多，程式集衝突、服務變更重啟叢集影響範圍大等問題依舊是難解的問題。所以為了隔離變化、降低對其他服務的影響，叢集的劃分粒度會越來越小，甚至演變到一個服務一個叢集，這就是微服務的形態了。這幾種架構模式總結起來就是水平、垂直兩個維度變化，水平維度從一類網站變為了多類網站，以解決變化的影響訪問、代碼複用的問題。垂直維度從所有應用部署在一個網站中，變化到一個服務一個叢集，隔離變化帶來的影響。架構從一個點演變到兩個維度變化，最終帶來的營運成本指數級的增長。下面是特來電雲平台微服務架構圖，可以看出，整體架構比較複雜。

      為了支援全國的充電業務，特來電雲平目前已經有近千台伺服器，應用程式100類+，WebAPI介面2000+，服務介面500+，開發測試環境幾十個，僅僅產生環境每天熱更新就會高達20次+。20多次的熱更新，都必須經過單元測試後，部署到與生產環境近乎一致的測試環境中進行介面測試、UI測試，然後再在准生產環境中進行迴歸測試，最終才能灰階發布到兩個資料中心。說到這裡，大家很可能會想到通過DevOps來規範環境的同步：CI完成後，通過CD把產品更新部署到多個環境進行測試，然後發布到生產環境。是的，正常情況下，這個流程沒問題，但是現實非常殘酷。有太多的因素導致測試環境與生產不一致。下面就簡單說說：

1. .net Framework 無法採用Docker，更新包中不僅僅有程式檔案的更新、還有配置的更新、SQL的更新。在如此大的規模下，人工更新成本高的離譜，基本上需要專崗來做。而人工做，很容易出錯。必須工具化、自動化，補丁更新必須100%通過工具做，不能有人工幹預，否則就會在各個環境中出現不一致的情況。
2. 系統幾乎每個小時都會發生一次變化，常見的增減應用程式、增減服務、增減WebAPI，這些資訊的變化都會影響系統內容。只要一個程式、介面、服務管理不到位，系統就可能會給你顏色看。所有的機器資訊、服務資訊、配置資訊必須集中管理維護，並在各類環境中實現自動同步。CMDB是必備的管理系統。
3. 在日常的研發中，很多需求會涉及到多個產品研發部門聯合開發，整合測試的周期很長，而測試環境的數量有限，經常出現一些緊急需求沒有測試環境的尷尬問題。
4. 測試環境會頻繁的執行更新，甚至一個更新會反覆多次，極易導致測試環境與生產環境不匹配。從而引起，程式熱更新後存在bug，需要緊急回退。
5. 開發測試環境是對每個開發人員開放的，每個人都會登入系統Debug。你懂的，只要Debug一次，程式很大幾率就會發生變化。
6. 一個業務可能需要幾個、甚至十幾個程式提供服務才能正常運行，一個環節出現問題，整個系統就會出錯。如何快速的分析、排查問題，是個痛苦的問題。這是讓很多人抓狂的問題。
7. 。。。

      在面對如此多的變化時，DevOps變的很理想、很無力。DevOps的落地，需要在不斷的改良中找到平衡點。我們的解決方案是：

• 搭建CMDB系統，管理各類環境的部署資訊。比如：叢集資訊、進程資訊、服務資訊、WebAPI資訊、配置資訊等。並且這些資訊的變更要通過系統集中管理，決不允許出現CMDB資訊與部署資訊不一致的情況。
• 搭建補丁系統。開發交付包標準化管理。通過補丁製作工具，製作格式化的補丁，通過補丁安裝平台，實現補丁包的安裝。系統程式、SQL的變更全部通過補丁平台進行。補丁系統是一個非常複雜的系統，後續有機會再詳細介紹。

• 搭建模板機環境，當生產系統更新了補丁或者CMDB資訊發生變化後，通過自動化的工具，主動推送到模板機中。保證生產環境與測試環境的即時同步。各類測試環境從模板機複製，並通過工具與模板機定時同步變化。同步完成後，通過自動化測試載入器和環境檢查工具，確定環境是可用的。

• 開發全鏈路監控系統，並在系統的各個入口處埋點，協助開發人員分析系統問題。全鏈路監控系統也是一個非常複雜的系統，後續有機會再詳細介紹。下面是全鏈路的基本原理圖和運行。

      做互連網應用需要有基因，更需要有填坑的勇氣和毅力，填坑的過程就是攀登技術高峰的過程，永無止境！本文也僅僅是從架構的方面給大家分享，不過內容全部已經落地，沒有吹NB的意思。希望這個技術分享能對大家有用！

 分類: 架構及擴充

net的微服務架構