在GOTO Berlin2015大會上，Alexander Heusingfeld進行了一場名為“當微服務遇上實際項目”的演講。InfoQ對Alexander Heusingfeld與他的同事Tammo van Lessen進行了一次采訪，談到了如何讓來自運維團隊的人員參與架構、在實施DevOps實踐時如何處理“各管各的”這樣的行為、如何通過自包含的系統方式實現現代化的軟件系統、自包含的系統與微服務之間的相似之處與差異、如何改進部署管道并在部署時進行測量。還談到了Alexander在一個“離開自己熟悉的領域”的活動中獲得的經驗。

InfoQ：你如何向來自于系統運維團隊的人員推薦某種架構，這對于他們來說有什么意義？

Heusingfeld：只有實際進行日常業務工作的人員接受了某種系統架構，這種架構才能夠體現出價值。因此，在開展一個新的項目時，我的第一步總是嘗試與來自于運維團隊和業務部門的人進行交流，并認真地傾聽他們的聲音。他們都很擅長于介紹公司和流程，以及流程對于日常業務的影響。在討論系統的新特性、流程的變更或改進時，這些見解的價值是無可估量的。一旦他們感到自己的想法得到理解，并且意識到我確實考慮到了他們的關注點，那么我就完全不必刻意地推銷我的觀點了。

van Lessen：這主要取決于人與人之間的信任。我經常需要面對一些來自于運維團隊的成員，他們對于新的思想或技術顯得非常抗拒。我想這是因為他們對于維護與支持新的系統感到不安，其實他們可能還沒有完全從運維的角度理解這種變化，也不明白這些技術對于項目的重要性。項目成功的一個重要因素是讓這些成員盡早地參與到項目的架構設計階段，這種做法能夠在團隊中實現思想的共享，在整個團隊中的開發與運維工作這兩方面達成互相依賴與互相理解。

InfoQ：在實施DevOps時，來自于不同部門的人將成為同一團隊的成員，這使得實施工作將面臨許多挑戰。當你希望團隊成員之間能夠密切合作時，對于可能出現的“各管各的”這種表現，你有什么建議？

van Lessen：DevOps正是克服“各管各的”這種行為的第一步，它意味著成立一個跨職能的團隊。傳統的做法是通過一些刻板的流程人為地建立一條鴻溝，然后不斷地調整某個團隊如何將信息丟給另一個團隊的做法。我非常確信，與之相比，實施DevOps團隊所面對的挑戰要小得多。真正的挑戰在于如何讓采用傳統做法（或類似做法）的公司轉而采用新的做法。在許多情況下，讓人們放棄陳舊的習慣而采用新的途徑總是非常困難的。

Heusingfeld：我們經常注意到一個現象，當來自于不同部門的人組成了一個跨職能的團隊后，有可能會產生小團隊之間的戰爭，尤其是在保持了傳統的部門結構的情況下。這也是為什么我認為所有團隊成員的最高優先任務必須是實現團隊的目標。部門的直接領導絕不可為某個團隊成員安排更高優先級的任務或與團隊相抵觸的任務。在這種情況下，團隊成員要么被迫加班，要么就得讓其他成員失望。如果這種情況持續發生，那么團隊成員之間就將失去信任。正如我們所知，如果我們無法信任某人，那么也無法在關鍵性的場合中依賴他們。具體來說，這意味著無法相互信任的團隊成員也無法實現最佳的效率，并且在面對壓力時很可能會很掙扎。因此我們建議在成立團隊時進行一些團隊建設，在團隊成員之間建立信任關系。

相關廠商內容

Druid項目聯合發起人探討開源大數據技術之演

Facebook的項目開發流程和工程師績效管理機制

百鬼夜行の看不見的無線安全

支付寶絲般順滑的春晚的保障機制

滴滴出行iOS客戶端架構演進之路

相關贊助商

QCon北京2016大會，4月21-23日，北京·國際會議中心，精彩內容邀您參與！

InfoQ：你在GOTO Berlin大會上提到了一種自包含系統的架構方式，你能否概括性地解釋一下這種方式？

van Lessen：自包含系統（SCS）描述的是一種構建軟件系統的架構方式，例如將一體化的架構切分為多個功能相互分離，而又保持自治的web應用。關鍵在于，SCS應當負責自己的UI以及數據存儲部分。系統的邊界展現了一個垂直的分片，這在領域驅動設計（DDD）中被稱為“邊界上下文”。在多數情況下，整個應用是通過連接與嵌入的方式在瀏覽器中將每個SCS部分整合到一起的。這些系統既不會共享某種通用的UI代碼，也沒有通用的業務邏輯。每個系統可能都是由獨立的團隊自行選擇技術進行維護的。如果做得足夠好，那么終端用戶將能夠流暢地游走于各個系統之間，通過點擊連接或單擊按鈕的方式跨越應用的邊界。在理想的情況下，用戶甚至不會注意到他們已經離開了某個系統而進入了另一個系統。通過漸進增強的方法，這種架構方式將能夠支持所有瀏覽器，從陳舊的到現代化的、從屏幕閱讀器到移動電話。有些應用會直接顯示跳轉至某個系統的鏈接，而有些應用會將連接替換為某種在視覺上效果更好的方式，但所展示的內容是相同的。

Heusingfeld：我注意到，來自于運維團隊的成員認為自包含系統（SCS）架構方式是一種合理地構建與保持系統現代化的方式。在我看來，SCS有助于避免由于過多的復雜性而壓垮團隊成員。這一點對于我來說至關重要，因為正如我之前所說，負責每日業務的人需要理解你打算引入變化的原因與做法，才能夠支持你的工作。我們還收集了大量有關SCS方式的內容，對此有興趣的讀者可以訪問http://scs-architecture.org/，并參與我們的討論。

InfoQ：你能否舉幾個例子說明如何運用自包含系統方式構建現代化的軟件系統？

Heusingfeld：關于SCS方式的應用有兩個非常有力的例子，即otto.de（請參與德語的Otto TechBlog）以及Galeria Kaufhof。在scs-architecture.org網站可以找到更多的參考資料與文章。除了學習案例之外，另一個有趣的方面是如何在不下線的情況下將一個一體化的架構切分為SCS架構。正如我們在演講中提到的，我們收集了一些典型的改進方式，成功地用于改進系統的過程中，并將這些內容以一個名為aim42的架構改進方法的名義進行發布。尤其是其中“干掉壞的部分”以及“通過萃取進行改變”這兩種策略由SCS進行實現看起來是很自然的選擇。在這兩種情形中，你首先要在你的一體化應用中找到那些需要移植到新系統中的功能。SCS將解答你關于如何切分舊系統的疑問：找到這一功能對應的業務領域，將其放入在SCS中同樣只負責這一領域功能性代碼，即包含相同用例的對應位置。如果你的一體化架構無法做到清晰地分離業務領域，SCS方法能夠為你提供一定的自由度，以實現粗粒度的步驟。例如你可以首先將一個一體化架構分為兩個SCS系統，然后通過小型的迭代逐步改進。在aim42中對此專門有一個改進方式，名為“通過切分進行改變”

InfoQ：你能否詳細地解釋一下自包含系統方法與微服務之間的相似點與區別？

van Lessen：SCS與微服務之間有許多概念是相通的。例如在技術選型中保持靈活性與多樣性、保持組織邊界與架構邊界的一致性、以及通過獨立的可部署單元實現功能的隔離。不過，SCS顯然更為粗粒度一些。實際上，SCS應用可以由內部的微服務組合實現。SCS的意圖是在UI層進行整合，而微服務比較多的是在一個較大的應用的邏輯層進行組合。因此，雖然兩者都基于同樣的思想，但SCS將微服務原本的思想推到了一個宏觀的層面上。

InfoQ：有人可能會說，既定的流程可能會限制部署的速度，你們對此有什么建議？

Heusingfeld：有些時候，如果在交付流程中需要進行合規性與安全性的審計，或是需要進行大量的手工測試，那么你確實有可能會聽到這種說法。從我的經驗來看，人們在流程變更的一開始通常會產生排斥的態度，其原因一是他們不相信最終的益處會像宣告中說的的那么好，二是他們認為不值得付出那么多精力。因此，我不建議一上來就嘗試將所有過程都自動化，而是選擇較小的步驟，從與你最相關的部分開始自動化。要實現軟件部署的自動化，例如在開發團隊中搭建一臺類似于Jenkins的CI系統的服務器，這種事一般不會遇到什么合規性問題。可以通過這種系統實現自動化驗收測試，為團隊提供快速的反饋，以了解應用的行為是否符合預期，或者是否破壞了某些功能。一旦團隊表現出了速度與質量方面的提高，團隊的經理就能夠向管理層分享這個“成功信號”。這樣，其他團隊也能夠認可他們的做法，如果能夠找到符合自己需求的益處，這些團隊也很可能開始實施這些實踐。因此，即使你在交付過程中需要手動操作，也可以持續地進行改進并逐步地實現自動化，可隨意選擇在手動操作過程之前或之后執行這些自動化腳本。整個過程就像是工廠中的生產線一樣運轉。

van Lessen：盡管如此，但在某些情況下，這種規則確實是無法改變的。我曾經在一些大公司中遇到這種問題，他們的IT部門并非頭等公民，而只是實現目的的一種手段而已。他們的核心業務都建立了嚴格的流程制度，然后同樣延伸到了IT部門。這種情況下，IT部門基本沒有什么力量去主動地打破公司級別的規章制度。不管怎樣，在一些流程的邊緣地帶，仍然有機會盡量實現一些自動化過程。

InfoQ：你們能否分析一下，如何通過透明的部署管道探索及改進軟件的交付過程？

Heusingfeld：我們曾遇到過一個客戶，他希望“晚一點再實現自動化”，其原因正如我在之前的例子中提到的“合規性”問題。他們也通過KPI（關鍵業績指標）衡量某個軟件的特性是否成功。因此，在軟件真正部署到生產環境并獲得KPI指標之前，團隊完全不知道他們是否在做正確的事。我們決定檢查一些這些指標數據是如何收集的，隨后便發現我們應該在部署到生產環境之前獲取這些指標。最終，我們不僅在集成測試的系統與手動測試階段就收集到了這些指標，并且通過修改與添加自動化驗收測試，在早期于開發服務器上進行的驗收測試過程中，我們也能夠獲取第一批結果。通過這種方式，開發者在將代碼提交到遠程Git庫的5至15分鐘后就能夠大致了解運行情況了。這樣的洞察力能夠讓整個交付管道達到一個嶄新的透明度，并且在團隊的交付與工作中建立了信任關系，尤其是對于產品負責人來說。

InfoQ：你們能否舉例說明在部署管道中如何進行檢測？這種檢測對于開發者來說有什么價值，他們應當如何利用這些檢測結果？

van Lessen：在我看來，人們對于從應用與系統中獲取運行時指標的做法還沒有足夠的重視。雖然實現這一點需要付出額外的努力，但它對于一個更專注的開發過程是一種非常有力的促進。我們通常會劃分出三種指標：業務指標能夠解答C級別（CIO、COO等）管理者經常提出的一些問題；應用指標能夠獲取應用本身的健康和性能狀況；系統指標則獲取硬件與操作系統的信息。當你的指標覆蓋了所有這些信息之后，就能夠更深入地理解應用在每時每刻的行為。從運維的角度來說，這對于生產環境來說是最迫切的。但正如Alex所說，這些信息也為開發者提供了一些見解，以持續地分析他們的實現的質量。我舉一個具體的例子：用戶抱怨說報表的生成時間太長，而你從“太長”這個描述中無法獲得任何信息。生產環境中的指標能夠立即回答這一問題，而從一個運行在CI系統中的測試過程中所獲得的同一指標則能夠幫助開發者分析如何解決問題。這里可能包含了多個不同的指標，業務指標或者是“我們每天能夠生成多少份報表”，而應用指標則回答你的疑問，到底是數據庫訪問還是PDF的生成消耗了更多的時間。如果CPU處于空閑狀態（系統指標），而報表的生成依然很慢，那可能是出現了并發問題，例如連接池中的連接都處于阻塞狀態因而沒有可用的連接。而在部署管道中，同樣的指標則能夠更早的回答一些疑問，例如“新的代碼是否有所改進？”。在理想的狀態下，開發者在提交代碼后就能夠立即知道答案。這種做法也能夠讓找到某個問題的解決辦法更簡單。

Heusingfeld：眾所周知，持續交付管道能夠帶來快速的反饋，并讓開發者能夠更多地接觸到許多問題的解答，而我們則充分地利用了這一點。通過對堆的使用、CPU的利用率、或網絡及磁盤的I/O進行分析，我們就能夠指出某個代碼改動是否對應用的性能產生了負面的影響。不僅如此，我們還能夠做到更進一步。產品負責人通常會對生產環境中的KPI進行分析，以檢查產品的表現情況。這些指標可能包括“結賬流程的時間”或“過去24小時內新注冊客戶的數量”。我們可以向產品負責人了解有哪些指標將用于計算他們的KPI，并嘗試在運行自動化測試的環境中對這些指標加以分析。這種做法可能不適用于所有生產環境中的KPI，但或許比你想象中要多。

InfoQ：你在演講中提到，在你之前的某個公司中，曾開展過一個“離開自己熟悉的領域”的活動。你能否分享一下你的經驗，以及從這一活動中學到了什么？

Heusingfeld：這家公司為員工安排了一個項目，讓每個人都在一個陌生的部門中工作一天時間，至少每三個月就要進行一次。負責控制系統的員工可能會出現在數據中心里，市場人員可能要去倉庫，而開發者也可能要參與HR團隊的工作。我本人當時在IT部門為銷售點開發一個Java應用，我很樂意與一名銷售經理一起訪問幾家店鋪。這不僅能夠讓我看到所開發的軟件得到了實際應用，他還要求我通過這一軟件銷售產品。這為我提供了一個全新的視角，我終于意識到在軟件測試過程中將自己想象為一名用戶與在現實生活中的實際應用是完全不同的：銷售要面對壓力與催促，這已經改變了我的使用行為，并且銷售點的環境與一個受到保護的辦公環境中完全不同的。這次體驗對我來說是無價之寶！還有一次，一位物流組的員工來到了開發部門，你可以想象人們會對他多少有些偏見。大家都不知道如何與他共處，因為“他完全不懂寫代碼”。因此大家決定帶他四處看看，讓他了解軟件是如何構建的，并通過一些易懂的圖形為他解釋我們的交付流程。結果這家伙突然冒出了一句話：“抱歉，如果我理解的沒錯，如果你們真的這么做，那么就是在浪費時間”。每個人都為此感到震驚，并要求他解釋。他用了兩個小時描述了他的觀點，并指出了我們的流程中某個低效的地方，而我們自己這幾個月都沒有發現這一點，這真是上帝的賞賜。我從這些經驗中至少學到了兩點，即“別讓偏見蒙蔽了你的雙眼”，以及“經常換一個角度思考！”。

關于受訪者

Alexander Heusingfeld是德國innoQ公司的一位軟件架構與工程方面的高級顧問。作為一位顧問、軟件架構師與開發者，他以他對Java以及基于JVM的系統的長期了解為客戶提供支持。他經常參與企業應用整合（EAI）、現代web應用以及微服務架構的設計、分析以及實現工作。他樂于為開源項目貢獻代碼、在IT大會與Java用戶組中進行發言，并偶爾會在http://goldstift.de上發表一些博客文章。

Tammo van Lessen是德國innoQ公司的軟件架構與工程方面的首席顧問，他同時被選為Apache軟件基金會的一名成員，以及Apache ODE的PMC主席。他參與了一本有關WS-BPEL的德文書，也是OMG（對象管理組織）的BPMN 2.0 Finalization Task Force的一名成員。他自認對于軟件架構、DevOps和現代化監控工具的尺度總是掌握不好。他曾在Web service與業務流程執行方面發表了一些學術性與非學術性的文章。同時，他也經常在國內與國際性的大會上進行演講。

查看英文原文：Microservices in the Real World