在柏林舉辦的microXchg大會上，一組軟件開發實踐人士分享了關于微服務架構風格的最新理念。討論的話題包括功能性服務設計（Functional Service Design）、集成領域驅動設計（DDD，Domain-Driven-Design）和REST、使用嵌入技術（Transclusion）創建基于微服務架構的網站、微服務運行時平臺的選擇、微服務對企業和員工的影響，以及如何在物聯網應用中使用微服務。
microXchg微服務大會的開場報告是由Uwe Friedrichsen呈現的，報告探討了“彈性功能性服務設計”中的核心理念。InfoQ新聞已經報道了該演講的細節內容，關鍵要點包括：微服務開發人員應該學會容錯設計模式（例如回路熔斷器和艙壁）和緩存，但不能用于改善已經很糟糕（過度耦合）的系統設計；理解領域驅動設計（DDD，Domain-Driven Design）和模塊化的重要性；注重可替換性而非可重用性；對系統的動態行為建模等。
不要從靜態領域模型著手，能夠給我們帶來驚喜的是系統的動態行為。
之后Oliver Gierke呈現了他的報告“DDD和REST：領域驅動設計API還是Web”。他在報告一開始就向聽眾推薦了InfoQ的《領域驅動設計快速入門》一書，因為這本書提供了很好的DDD核心理念入門。Gierke建議軟件工程師在開發領域模型時應盡量“使隱藏的概念清晰化”，并推薦通過觀看“在DDD中大規模使用Value Object”，以進一步理解報告的主題。雖然一些開發人員可能會參考數據庫模式建立傳統的領域模型，但是DDD類型的模型比簡單的外鍵關系等其他模型更能清晰地表達業務理念。
DDD領域模型比數據庫模式揭示了更多的信息。
Gierke明確指出，REST并不等同于“提供HTTP的CRUD”。在設計展現給用戶的數據（即視圖）時，必須注意要加入對這個問題的關注。報告中展示了一個API操作的四層模型，該模型涵蓋了四個方面的內容，它們分別是：借助API的顯式操作、一些事件形式的操作、事件溯源（ES，Event Sourcing）和命令查詢職責分離（CQRS，Command Query Responsiblility Segregation）。Gierke指出，“超媒體即應用狀態引擎（HATEOAS，Hypermedia As The Engine Of Application State）”這一概念對于客戶通信而言非常有用，可被用于與支持動作和狀態轉移的客戶端交互，而非將它們發布為獨立的領域相關文檔。這或許是通過增加領域知識的復雜性來降低客戶端協議的復雜性，但是Gierke建議聽眾考慮一下這種權衡是否有用：
HATEOAS被用于給支持動作和狀態轉移的客戶端發出指示。這或許是通過增加領域知識的復雜性來降低客戶端協議的復雜性，但是你應問問自己：“什么會變更得更頻繁，是業務規則還是所使用的協議？”
第三個報告是由Gustaf Nilsson Kotte呈現的“微服務網站”，報告探討了高效構建網站的原則，這些網站雖然以單一站點形式交付，但是由多個微服務組成。報告的核心前提是每個微服務應該提供自己的前端，面向用戶的頁面應該使用嵌入技術構建。“頁面片段緩存（ESI，Edge-Side Includes）”可以在服務器端提供嵌入技術，例如通過Akamai或Varnish。還有一些框架在基于JavaScript的客戶端提供嵌入技術，例如AngularJS和h-include。報告中展示了每種方法的一些優缺點。
服務器端嵌入技術對比客戶端嵌入技術
Kotte在對報告做總結時指出，基于微服務的網站應以持續集成、去中心化管理和優化移動設備和蜂窩網絡的性能為目標。在不考慮全局客戶端依賴的情況下嵌入（Transclusing）服務器端資源，這可作為一種分解網頁（和微服務）的方法，這個方法可以推動上述目標的達成。更多信息可以閱讀Kotte在近期撰寫的“微服務網站”一文。
此后，Dustin Huptas做了名為“AaaS，任何事情即服務。我們應如何選型？”的演講。他提請聽眾注意，雖然一些服務提供商提供了以“某事即服務”命名的部署平臺，但是應該慎重選擇最適合自身應用的解決方案。Huptas認為單體應用和經典的SOA應用最適合運行在物理的基礎設施和基礎設施即服務（IaaS，Infrastructure as a Service）上，基于微服務的應用最適合使用Iaas、平臺即服務（PaaS，Platform as a Service）以及新出現的功能即服務（FaaS，Function as a Service），而“無服務”類型應用最適合使用PaaS和FaaS。
架構/技術即服務模型。
Huptas給出了一種“自適應IT立方體”，并探討了從任一部署平臺遷移到其它平臺時所應考慮的架構、技術和企業（包括文化和過程）問題。必須注意要使用漸進的方式做遷移，而且遷移行動必須得到企業的認同。例如，軟件應用的遷移或更新應該具有長期的承諾。
隨后，Daniel Bryant（即這篇新聞的作者）做了題目為“微服務：對企業和員工的影響”的報告。報告的核心內容指出了采用微服務時存在著很多挑戰，這些挑戰主要圍繞著企業、過程和人員方面的問題。Bryant建議在實現一個基于微服務的應用時，企業應該聚焦于定義和溝通清晰的目標（包括商業價值和技術策略），在整個企業和技術棧上做優化反饋，并確保在企業中清晰地定義職責。
策略愿景的溝通。
Bryant建議企業在設定目標前必須對狀態有一個清晰的認識，并建議使用 Wardley映射和價值流程分析工具。強大的技術領導力（在整個團隊中共享）同樣非常重要。此外，“InnerSource”模型有助于更好地應用從大規模開源項目中獲得的經驗教訓。為顯示業務價值、架構質量和操作的有效性，必須將度量和信號“添加”到微服務中。Bryant在對演講做總結時，建議在采用DevOps方法的開始階段就要定義好職責，并指出持續集成通常是驅動軟件交付過程持續改進的催化劑，尤其當構建基于微服務應用的集成復雜度與日俱增。
第一日大會以Fred George的主題演講“家庭中的物聯網和微服務”結束。George指出，我們當前生活在一個“智能代理時代”，充斥著智能助手技術，例如Apple Siri，Google Home和Microsoft Cortana。這些物聯網技術的主要創新點并非在于語音識別技術上，而是在于可以由終端用戶創建的后臺服務交互。
George展示了自己家中部署的物聯網技術，其中包括 Amazon Echo、Phillips的物聯網燈泡、Apple TV和具備物聯網功能的交換機。這些設備的控制軟件是使用Ruby和Java開發的微服務，它們通過Docker Swarm部署，并使用RabbitMQ事件總線作為通信手段。將所有物聯網設備黏合在一起的軟件開發技術原則包括：即時（just-in-time）設計、實現極小化的面向行為服務、將動作和結論作為全局事件進行發布，以及基于硬件的冪等性和冗余性構建可靠性。
microXchg大會于今年2月16日到17日在柏林召開。可以在大會的YouTube頻道上看到所有報告的視頻記錄。
查看英文原文： microXchg Microservices Conference Day One Summary: DDD, Platforms, and Organisational Impact
京公網安備 11010502049343號