2.4 流程管理

微服務從技術架構出發，使應用系統具備快速響應、靈活部署、敏捷交付、持續演進的特性成為可能，而規?；奈⒎战桓度绻麤]有完整的軟件工程和流程管理體系、自動化的流程交互運維工具，很難持續發展。

2.4.1 敏捷方法論

最早的軟件開發是沒有標準的，軟件質量好壞完全取決于軟件工程師的能力和素養。伴隨著軟件行業的發展，軟件的整個開發流程需要一套方法論來規范，CMMI（Capability Maturity Model Integration，即能力成熟度模型集成）這種基于瀑布模式的標準軟件開發流程解決了軟件開發的標準化問題。在CMMI體系下，軟件開發逐步向工程化邁進，但是也缺少了動態性和靈活性，人們開始反思傳統方法的弊端，進而提出了敏捷方法。

2001年2月，由Martin Fowler等17位軟件開發專家起草的敏捷宣言發表，敏捷聯盟成立。我們可以看到一個熟悉的名字：Martin Fowler，微服務架構的概念最早也是他提出來的。

下面我們了解一下敏捷宣言中敏捷軟件開發的四個核心價值觀。

● 個體和互動高于流程和工具：這里強調了人與人直接溝通的重要性和高效性，所以有了站立會議。但不要理解為完全不需要流程和工具，只是側重人與人的溝通。

● 工作的軟件高于詳盡的文檔：這里強調把更多的時間放在開發軟件上。但并不是說文檔就一點也不要寫了，關鍵性的文檔（項目整體流程描述及架構圖等）還是要有的。

● 客戶合作高于合同談判：這里要區分公司屬性，外包公司團隊和企業自有項目團隊肯定會采取不同的策略。這句話應該是講給企業自有項目團隊的，為了企業合作雙方的利益，這個觀點是正確的。但并不是說毫無底線地向客戶妥協，而是提倡密切合作，以便提前發現問題，雙方都可以減少損失，實現共贏。

● 響應變化高于遵循計劃：這里道出了軟件開發不可回避的問題，就是需求變更。站在企業整體利益的角度，需求變更是很正常的。隨著市場變化、時間推移，之前的需求如果不做修改可能真的就影響了產品的落地效果。但這也不是說需求可以任意地變來變去，需要有既懂業務又懂技術的人來負責評估。

Scrum（迭代式增量軟件開發過程）是實現敏捷開發的具體方式之一，是一種具體實施方案和流程，也稱為過程管理框架。Scrum的主要原則是縮短軟件的交付周期，通過將過程分解為短期的工作循環，每一個循環為一個Sprint（沖刺），在每個Sprint中，由項目團隊確定目標，Scrum團隊由不同類型的人員組成，包括開發、測試、業務人員、美工等，每個團隊的目標由項目管理者在計劃會議上確定，團隊可以自行確定實現Sprint目標的方法和途徑，可以自行管理日常工作和計劃的執行。

微服務架構與敏捷研發流程一脈相承。微服務是將一個完整的系統分割成若干微小的、具備獨立性的功能單元，每個功能單元是可以具備一個實際意義的小功能集。各個功能單元之間盡量是解耦或松耦合的，可以實現獨立開發而不依賴其他功能單元。而敏捷保證微服務架構能夠更好地適應需求的變化，保持團隊的高效溝通，敏捷利用小型工作增量、頻繁迭代與原型設計等手段，可以使我們擺脫大規模單體軟件開發的風險。

微服務架構更多地從技術的角度提升開發和運維的效率，而敏捷方法論貫穿了軟件工程的整個流程，它重視流程、溝通、協作?？梢哉f，敏捷在管理流程上是對微服務架構落地的有益補充和保障。

2.4.2 DevOps轉型

隨著軟件開發敏捷化的推進，DevOps正在成為軟件交付的最佳模式。DevOps是一種研發模式和一種方法論，從2009年開始逐漸流行起來。它不是框架或技術的東西，是更好的優化開發（DEV）、測試（QA）、運維（OPS）的流程，使開發運維一體化，通過高度自動化的工具與流程來使得軟件構建、測試、發布更加快捷、頻繁和可靠。DevOps的主要目的在于提高產品的交付能力與效率，要踐行DevOps首先要改變的就是管理理念。

DevOps其實包含了三個部分：開發、測試和運維。從單體架構轉型到微服務架構后，我們可能面臨開發、測試和運維諸多挑戰，微服務架構需要借助DevOps方法論進行持續開發和持續集成的原因如下：

● 服務拆分成為細粒度的服務后，服務之間需要持續集成，才能完成整體的功能迭代，需要自動化測試、自動化交付。相比單體架構，微服務架構有更高頻率的軟件部署集成、發布、交付訴求。

● 大多數微服務架構使用容器和云平臺，需要在流程上支持快速的發布流程，支持規?；奈⒎战桓秷鼍啊?/p>

● 要理解微服務之間的復雜交互，需要優秀的診斷與監控工具，而軟件系統診斷與監控不僅僅是運維人員的職責，開發人員也需要深入參與到軟件的交付和后期的系統運維和運營中，提升微服務之間交互的可觀測性。

軟件團隊DevOps轉型需要從下面幾個方面展開，這其中不僅包含技術的轉型，也包含組織、流程等關鍵要素的轉型。

● 技能方面：團隊需要不斷引入優秀的技術和好的設計來增強敏捷能力；保持良好的軟件架構風格；集成工具鏈，搭建自動化軟件集成、交付、發布平臺。

● 組織與流程方面：DevOps需要組建一個自治的團隊，使團隊向全棧開發方向成長。另外需要融合不同的職能人員，比如開發人員和運維人員工作在同一個部門，向同一個領導匯報。要求開發人員和業務人員在整個項目開發期間必須天天在一起工作。需要建立激勵體制和反省體制，團隊每隔一定的時間在如何才能更有效地工作方面進行反省，然后對自己的行為進行調整。開發人員需要遵守相應的原則來保證進度。軟件進度的唯一標準就是“能使用的軟件”，優先要做的事是通過持續地交付有價值的軟件來使客戶滿意。為了達到這個目的，在開發過程中要最小化可執行產品，持續集成/持續交付、持續部署（CI/CD），測試驅動開發（TDD[2]）。交付的時間間隔越短越好，使用戶經?？吹杰浖Ч?。其中測試驅動開發可以優化代碼設計，提高代碼的可測試性，建立和代碼同步增長的自動化測試用例，根據迭代積累的經驗和需求變化情況對計劃進行不斷的調整和細化。

● 文化建設方面：實行激勵機制，通過建立激勵制度，強化和獎勵那些引導組織朝著目標前進的行為。舉行每日站立會議，進行高效的會議、記錄問題并跟蹤問題的解決過程；進行可視化管理，可視化管理可以讓所有團隊成員直觀地獲得當前項目的進度信息，及時暴露問題；保證團隊理解一致并且適應變化，團隊需要一定的敏捷理念，認清客戶是逐步發現真正的需求的。

總之，DevOps貫穿軟件工程的整個生命周期，DevOps不只包含CI/CD方法論，除了技術和流程，它還包含企業管理文化。

2.4.3 自動化管理工具

在DevOps實踐中，自動化管理工具的使用是非常重要的，下面讓我們看看一些常用的代表性工具。

● IT基礎設施自動化

云服務：使用公有云（如阿里云、AWS等）服務，不需要買硬件服務器、租用機柜。私有云服務可以基于Kubernetes進行擴展構建。

● 代碼管理

Git：存儲代碼，管理代碼的版本。

● 配置管理

Chef：它是一個非常有用的DevOps工具，用于管理配置文件。使用此工具，DevOps團隊可以避免跨10000臺服務器進行配置文件的更改，相反，只需要在一個地方進行更改，然后自動反映在其他服務器上。

● 自動部署

Jenkins：這個工具可以實行自動部署，有助于持續集成和測試。

● 交付鏡像

Docker：不僅可以交付軟件代碼，還能將代碼依賴的工程運行環境一同打包進行交付。

● 日志管理

ELK：這個工具可以收集、存儲和分析所有日志。

● 性能管理

App Dynamic：提供實時性能監控功能。此工具收集的數據有助于開發人員在出現問題時進行調試。

● 監控

Nagios：當基礎設施和相關服務宕機時，確保人們得到通知很重要，Nagios就是這樣一個工具，它可以幫助DevOps團隊發現和糾正問題。