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的微服務架構