“微服務并不是一切”：Fred George談論技術性、流程性與組織性障礙

在microXchg 2016大會上，Fred George進行了一場主題為“微服務并不是一切”（It’s Not Just Microservices）的演講。他在演講中表示，微服務確實能夠幫助組織“發展得更快”，并快速地交付商業價值。但他認為， 微服務的實現本身并不會帶來成功，必須找到在技術、流程和組織等方面對業務的敏捷性增長造成阻礙的原因，并沖破這些阻礙。

George 是Fred George Consulting公司的首席顧問，他在演講的開頭部分首先表示，當前業界存在著許多“熱門話題”，例如微服務、Docker和精益創業，這些話題都是圍繞著更快地交付商業價值的意愿而展開的。通過對于 Cynefin框架 的引用可以發現，許多組織所開展的業務是非常 復雜 的，由于這種復雜性，而無法確定因果關系，并且“目前有效的做法未必今后也同樣有效”。因此，如果期望在應對這種復雜性時能夠做到“更快地發展”，就必須找到在技術、流程以及組織方面的發展障礙并消除他們。

George引入了技術性障礙這一概念，為了詳細地討論這一問題，他首先對“硅谷科技”的爆炸式發展進行了探索。在 硅谷 地區，有大量成功的商業組織充分地應用了云計算、專用數據庫、開源框架與持續發布等技術，這就讓其他組織開始反思，是否他們自身在技術方面的選擇阻礙了他們的發展。尤其值得一提的是，如果組織將應用程序的部署從數據中心的裸機遷移至虛擬化的云平臺以及基于容器的環境，那么就能夠減少硬件的交付周期，進而縮短了應用的部署周期，這種差別往往是指數級的。

George認為，由于硬件的交付周期縮短，再加上現代化的硬件平臺具有更好的靈活性，這將促進服務設計的發展。久而久之，IT產業的革新者逐漸開始從單一的一體性應用轉變為由多個大尺度的面向服務架構（SOA）組成的服務。這一趨勢最終演變為由多個小規模的 單一職責 （微）服務所組成的系統，由此帶來了簡化代碼變更、縮小迭代規模以及更快的實踐等優點。

通過不斷發展的技術，我們將能夠創建松耦合、高性能的應用架構，例如使用（利用 Kafka 等技術）持久化事件總線，并通過一個輕量級的消息代理（messaging broker）以減少對于核心事件總線（通過 Zero MQ等技術實現）的讀操作的負載。在同樣由George所主持的另一場演講“實現微服務所面臨的挑戰”（ Challenges in Implementing Microservices ）中，他還將對這一概念進行進一步的探索。

George為聽眾舉了一個車輛租賃業務領域方面的應用示例，該應用通過某個服務向事件總線發送一條消息，基于客戶的數據發起一條租賃報價請求。而其他服務則能夠對該請求發出出價的回復。通過這種松耦合、異步消息驅動的架構，就可以輕松地添加新的出價服務（例如某個開發者認為他們實現了一種改進型的出價算法），并且由于單一的出價服務不會造成整個系統出錯的漣漪效果，從而也提升了系統的容錯能力。

在關于如何緩解技術性障礙的討論的總結陳詞中，George提出了開源所帶來的爆炸性優勢，如果組織無視一些現有的技術，例如 Netflix OSS 技術棧或 Docker ，那么就可能會將資源浪費在開發自有平臺上。此外，George還表示，對于某些用例來說，函數式語言或許能夠成為解決問題的“ 銀彈 ”。他提到了一個有趣的案例，某組織將一個包含13萬行代碼的Java遺留應用重寫為基于Clojure的應用，僅用了4千行代碼。

在演講的下半部分，George討論了如何緩解流程上的障礙，而解決這一問題的關鍵在于首先要理解組織所開展的業務。對于 明顯或有一定復雜度 的項目，可以通過傳統結構的軟件開發方式應對。但對于高復雜的問題則必須采用不同的策略。傳統的“瀑布”模型的做法是在項目開始時為開發團隊創建一個需求列表并進行任務分解，這種方式并不適合于處理復雜的問題領域，而應當采用“由實踐驅動創新”的方式，開發者應該轉而關注于“特性”層面，而不是繼續停留在任務層面。

項目干系人應當直接與開發者討論需要達成的業務目的、如何評價業務的成功，并且清晰地指出開發團隊可以選擇的“手段”。這一過程的關鍵在于“衡量重要的指標”，避免使用一些無用的指標，例如“代碼行數”以及“完成的里程碑”，而應當使用一些專注于業務的指標，例如銷售量、點擊次數以及客戶保留率等等。

在George談論如何緩解組織性障礙的開始，他提出了一點建議，即應當避免開發團隊任務的過度專業化。他發現，雖然理論上專職人員具有更好的生產力，但往往會受到過多的溝通與不均衡的工作安排的干擾，由此造成了工作的堆積與延誤。George為聽眾展示了某個組織的工作過度專業化的學習案例，他同時認為：各種漂亮的頭銜對于項目的業務價值交付毫無意義。

對于這個學習案例中所表現的過度專業化的問題，George提出了一種解決方式，即創建一份簡短的清單，列出對于組織有戰略性重要意義的關鍵技術，并基于 新手、熟練工及專家 的模型創建相應的頭銜。在這個學習案例中，新創建的頭銜包括：“新手開發者”，即還未掌握某項技術的人員。“開發者”，即掌握了某項關鍵技術的人員。“高級開發者”，即某項關鍵技術方面的專家。“系統開發者”，即掌握了5項或更多關鍵技術的人員。以及“開發者專家”，即3項或更多關鍵技術方面的專家。

除了頭銜的簡化之外，另一個關鍵在于組織的工作空間的安排，這種安排的目的是讓團隊能夠進行密切的合作，并且保證高效的溝通。團隊應當實現“ 不設立專職主管 ”，以避免在團隊中出現無謂的上下級結構，并且在處理因復雜的問題而出現不斷變化的挑戰時，這種方式能夠帶來更大的靈活性。而George所提的最后一條建議是“將工作安排給固定的團隊”，因為短期項目團隊的組建與解散是一種低效的方式，團隊需要一定時間才能夠 達到 較高的生產力。

George在本次演講的總結中說道，雖然對于復雜的業務領域來說，微服務是一種解決問題的好方法，但只有處理好其他技術性、流程性與組織性障礙的問題，才能夠有效地利用微服務交付商業價值。George最后向參加此次專注于開發者的microXchg大會的聽眾傳達了一條信息，他表示在開發團隊中必須有系統管理員與運維人員的參與（“DevOps”），并且應當擁抱全棧開發者的觀念。

Fred George在microXchg的演講“ 微服務并不是一切 ”的視頻可在大會的油Tube專屬頻道上觀看。

查看英文原文： “It’s Not Just Microservices”: Fred George Discusses Technology, Process and Organisation Inhibitors