第壹點:架構獨立性
任何體系結構都是為了滿足特定的業務需求而創建的。是否能在滿足業務需求的同時兼顧運維對架構管理的非功能性需求。那麽我們有理由認為這樣的架構是有利於運維的。
從運維的角度來看，所需的架構獨立性包括四個方面:獨立部署、獨立測試、組件化和技術解耦。
獨立部署
指源代碼，可以部署、升級、擴展等。根據管理要求便於操作和維護，並可區分地理分布進行配置。服務之間的相互調用是通過接口請求實現的，部署獨立也是運維獨立的前提。
獨立測試
運維可以通過壹些方便的測試用例或工具來驗證業務架構或服務的可用性。具有這種能力的業務架構或服務，使得運維可以獨立上線，每次發布或變更都不需要開發人員或測試人員的參與。
部件規格
意味著在同壹個公司內有壹個很好的相關技術的框架支持，避免不同的開發團隊使用不同的技術棧或組件，導致公司內部技術架構失控。
這種做法可以限制運維對象的無序增加，保持運維對生產環境的控制。同時也可以讓運維保持更多的精力投入去圍繞標準組件做更多有效率有質量的建設工作。
技術脫鉤
它指的是減少服務之間的相互依賴，也包括減少代碼對配置文件的依賴。這也是微服務、獨立部署、獨立測試、組件化的基礎。
第二點:友好部署
DevOps有很大篇幅講持續交付的技術實踐，希望從頭到尾打通開發、測試、運維的所有技術環節，從而達到快速部署、交付價值的目的。可見，部署是日常運維工作中非常重要的壹部分，屬於計劃性工作，重復度高，必須提高效率。
要實現高效可靠的部署能力，需要做好統籌規劃，確保部署和運行階段的全方位運維控制。與部署友好性相關的內容有五個緯度:
CMDB構型
在每次部署操作之前，運維部門需要清楚地把握應用與架構和業務之間的關系，以便更好地了解和評估全局的工作量和潛在風險。
在智雲自動化運維平臺中，我們習慣將業務關系、集群管理、運行狀態、重要級別、架構層等配置信息作為運維的管理對象管理在CMDB配置管理數據庫中。這種管理方式的好處顯而易見。集中存儲運維對象的配置信息，將為未來運維、監控、告警的自動化能力建設提供大量的配置數據支持和決策輔助。
環境配置
在運維標準化程度較低的企業，阻礙部署交付效率的原罪之壹就是環境配置，這也是容器化技術主要希望解決的運維痛點之壹。
在騰訊的運維實踐中，通過枚舉環境和運維操作相關的資源集合，結合自動初始化工具，實現開發、測試、生產三大環境的規範化管理。
依賴性管理
解決應用軟件對庫和運行環境依賴的管理。在織雲的實踐經驗中，我們通過將依賴庫文件或環境的配置打包為壹個整體，前後執行腳本，利用包管理解決不同環境下的應用軟件部署問題。業內有較輕的集裝箱化發貨方式，也是不錯的選擇。
部署模式
持續交付的原則是指建立壹個可靠的、可重復的交付管道，我們也根據這個目標強力規劃應用軟件的部署。行業內有很多案例可以參考，比如Docker的Build，Ship，Run，比如通過配置編織雲的描述，標準化流程的壹鍵部署等等。
發布自測
發布自測包括兩個部分:
應用程序的輕量級測試；
出版/變更內容的校對。
構建這兩種能力，滿足不同運維場景的需求。比如在增量發布中，運維人員可以快速獲取變更文件md5或者檢查對比相關進程和端口的配置信息，保證每次發布變更的可靠性。
同樣，輕量級測試是為了滿足發布時服務可用性檢測的需求。這壹步可以檢測服務的連通性，並運行壹些主幹測試用例。
灰色上線
《日常運維三十六計》中有壹句話:對於不可逆的刪除或修改，盡量推遲或減緩執行。這就是灰度的思想。無論從用戶、時間、服務器等緯度的灰度，都希望將線上運營的風險降到最低。業務架構支持灰度發布的能力，降低了應用部署過程中的風險，對運維更加友好。
第三點:可操作性
運維心目中最理想的微服務架構，肯定是運維強的那種。沒有可操作性的應用或架構，不僅給運維團隊帶來罵名，也深深傷害了他們的職業發展，因為維護壹個沒有可操作性的架構，根本就是浪費運維人員的生命。
根據操作規範和管理規範，可操作性可概括為以下七點:
結構管理
在微服務架構管理中，我們提出將應用二進制文件從配置管理中分離出來，從而達到獨立部署的目的。
對於獨立的應用程序配置，有三種管理方法:
文件模式；
配置項模式；
分布式配置中心模式。
限於篇幅，我們不討論以上三種方法的優缺點。不同的企業可以選擇最適合的配置管理方式，關鍵是要求所有業務使用壹致的方案，這樣運維就可以搭建配置管理的工具和系統。
版本管理
DevOps，連續交付的八大原則之壹，“將壹切置於版本控制之下”。就運維對象而言，要想管理好，必須能描述清楚。
與源代碼管理的需求類似，運維也需要對日常操作對象進行腳本化，比如包、配置、腳本等，以便在運維系統完成自動化操作時，準確選擇操作對象和版本。
標準操作
日常運維中有大量重復性的工作要做。從精益思維的角度來看，這裏有很大的浪費:學習成本、無價值的操作、多余的腳本/工具、人為執行的風險等等。
如果能在企業內部形成統壹的操作標準，比如文件傳輸、遠程執行、應用啟動和停止等。，這些都是標準化、集中化、壹鍵式的操作，運維的效率和質量都會大大提高。
進程管理
包括應用安裝路徑、目錄結構、規範進程名、規範端口號、起止模式、監控方案等。，都屬於流程管理的範疇。做好流程管理的全局規劃，可以大大提高自動化運維程度，減少計劃外任務的發生。
空間管理
做好磁盤空間的使用管理是保證業務數據有序存儲和減少計劃外任務發生的有效手段。
需要提前做好規劃:備份策略、存儲方案、容量預警、清理策略等。，輔以有效的工具，讓這些工作不再困擾運維。
日誌管理
日誌規範的實施和執行需要研發的密切配合，實踐中獲得的經驗和理想運維中的日誌規範應該包括這些要求:
業務數據與日誌分離。
日誌與業務邏輯是分離的。
統壹日誌格式
返回代碼和註釋很清楚
可用業務指標(請求量/成功率/延遲)
定義關鍵事件
輸出水平
管理方案(存儲時間、壓縮備份等。)
當能夠實現上述條件的日誌規範時，開發、運行和維護可以相應地獲得更好的監控和分析能力。
集中控制
運維工作本來就容易分成不同的部分，比如發布變更、監控分析、故障處理、項目支持、多雲管理等。我們呼籲建立壹站式的運維管理平臺，讓所有的工作信息都可以連接和傳遞，從而消除信息孤島或人工傳遞信息帶來的運營風險，提高整體運維管理的效率和質量。
第四點:容錯和容災
騰訊技術運營(運維)中的四個責任:質量、效率、成本、安全。質量是保證的第壹位。從架構的角度來看，運維眼中理想的高可用性架構設計應該包括以下幾點:
負載均衡
無論是軟件還是硬件的均衡解決方案，從運維的角度，我們總是希望業務架構無狀態，路由尋址智能化，自動實現集群容錯。
在騰訊路由軟件多年的實踐中，軟件負載均衡方案得到了廣泛應用，為業務架構高可用的實現做出了巨大貢獻。
可調度性
在移動互聯網時代，可調度性是容災容錯極其重要的運維手段。當業務遇到無法立即解決的故障時，將用戶或服務轉出異常區域，是在海量運營實踐中屢試不爽的技能，也是騰訊QQ和微信保證平臺服務質量的核心運維能力之壹。
結合域名、VIP、接入網關等技術，架構支持調度的能力，豐富了運維管理的手段，具有更從容應對各種故障場景的能力。
住在不同的地方
異地多活動是數據高可用的需求，也是可調度的前提。根據不同的業務場景，技術實現的手段沒有限制。
騰訊的社會實踐可以參考周曉軍老師的文章《兩億QQ用戶背後的架構設計與高效運營》。
主從切換
在數據庫的高可用性方案中，主從切換是最常見的容災方案。通過業務邏輯中讀寫分離，結合智能路由，實現無人值守主從切換的自動化，無疑是架構設計給DBA最好的禮物。
靈活可用性
“先穩住再優化”是騰訊海量運營思路之壹，也為我們做業務架構高可用設計指明了方向。
在業務量驟增的情況下，如何最大程度地保證業務的可用性？這是建築規劃設計中不可回避的問題。巧妙設置靈活的開關或內置邏輯自動拒絕超額請求，可以保證後端服務在關鍵時刻不雪崩，保證業務架構的高可用。
第五點:質量控制
保證和提高業務質量是運維努力的目標，監控能力是我們實現目標的重要技術手段。運維部門希望該架構能為質量監控提供便利和數據支持，要求如下:
指示器測量
每壹個架構都必須可以用指標來衡量，同時我們希望最好只有壹個唯壹的指標衡量。對於日益完善的業務立體監控，監控指標的數量會成倍增加。因此，我們希望架構只有壹個指標度量。
基本監控
指網絡、專線、主機、系統的低級指標能力。這些監測點大多是非侵入性的，很容易收集數據。
在壹個自動化運維能力健全的企業中，基礎監控產生的大部分告警數據都會有所收斂。同時，這部分監測數據將為高層業務監測提供數據支持和決策依據，或者被打包為更貼近上層應用場景的業務監測數據，如容量、多維指標等。
組件監控
騰訊習慣把開發框架、路由服務、中間件稱為組件。這種監控介於基礎監控和業務監控之間。運維往往希望在組件中嵌入監控邏輯。通過組件的推廣，提高組件監測的覆蓋面，獲取數據的成本適中。如果使用路由組件的監控，運維可以獲得每個路由服務的請求量、延遲等狀態和質量指標。
業務監控
業務監控的實現方式可以分為主動監控和被動監控，可以通過侵入式和旁路式實現。這種監控方案需要開發的配合，涉及到編碼和架構。
通常情況下，業務監控的指標可以概括為三個指標:請求量、成功率和延遲。實現的方法有很多，如日誌監測、流數據監測、波浪測量等。業務監控是高層次的監控，往往可以直接反饋業務問題。但要想深入分析問題的根源，必須結合必要的運維監控管理規範，如返回碼定義、日誌協議等。在設計業務架構時，要提前考慮運維監控管理的需求，範圍要全局規劃。
全鏈路監控
基礎設施、組件和業務的監控手段更側重於點監控。在分布式架構的業務場景中，必須考慮對服務請求鏈路的監控。
基於唯壹的事務ID或RPC調用關系，通過技術手段還原調用關系鏈，然後通過模型或事件觸發監控告警，反饋服務鏈路的狀態和質量。這種監控方式屬於監控的高級應用，在規劃業務架構時也需要預先規劃和代碼嵌入。。
質量評估
任何監控能力的提升和質量的優化都需要壹個閉環管理，而考核就是壹個很好的手段。從監控覆蓋面、綜合指標、事件管理機制到報告考核評分，運營和開發可以共同打造壹個持續反饋的質量管理閉環，讓業務結構不斷進化和完善。
第六點:性能成本
在騰訊，所有的技術運營人員都肩負著壹個重要的職能，那就是保證合理的業務運營成本。為此，我們必須對應用吞吐性能、業務容量規劃和運營成本有相應的管理方法。
吞吐量性能
在DevOps持續交付方法論中，測試階段的非功能需求測試最重要的壹點就是架構吞吐性能的壓力測試，以保證應用上線後業務能力的健康。
在騰訊的實踐中，性能壓力測試並不局限於測試階段。我們將結合路由組件的功能來測試服務模塊和服務集的真實請求，從而建立服務能力模型的基準。還從側面提供數據來論證業務架構的吞吐量性能是否滿足成本評估的要求，利用不同服務之間性能數據的比較來促進架構性能的持續改進。
容量規劃
英文單詞“capacity”可以翻譯為:應用性能、服務能力和總服務請求。運維能力規劃是指在應用性能達標的前提下，基於總的服務請求進行合理的服務能力規劃。
生產費用
降低運營成本對於公司來說就是減少了現金流的投入，對於企業的價值不亞於質量和效率的提升。
騰訊專註於社交網絡、UGC、雲計算、遊戲、視頻等富媒體服務。，而且每年消耗的帶寬、設備等運營成本金額非常巨大。運維優化運營成本往往涉及產品功能和業務架構的優化。因此，理想的運維業務架構設計需要有足夠的成本意識。
總結
本文純粹是我從運維角度對微服務架構設計的壹點拙見。為了實現運維價值最大化，保證業務質量、效率、成本的全面提升，業務架構這塊硬骨頭還得啃。
運維人員需要對架構有所了解，他們可以從不同的角度對業務架構提出建議或需求，這也是DevOps精神所倡導的。開發和運維協同工作，不斷優化最佳業務架構。