審視微服務架構：影響因素、運維複雜性和替代方案 ｜InfoQ 圓桌

{"type":"doc","content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"本文要點："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管業界已有一些遷移到微服務的成功案例，但依然有大量企業尚未接觸到微服務戰略。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當前的微服務方式比以往都要複雜。我們正構建越來越複雜的系統，使用越來越複雜的架構，進而導致我們舉步維艱，學習曲線陡峭。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"除了複雜性之外，如何監控和追蹤也是微服務面對的極大挑戰。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"事件驅動架構是構建微服務的很好方法，尤其是針對各服務間的通信。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"近期，"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/wesreisz","title":null,"type":null},"content":[{"type":"text","text":"Wes Reisz"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"針對“"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.com\/presentations\/microservices-roundtable-2020\/","title":null,"type":null},"content":[{"type":"text","text":"微服務的影響"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"”議題組織了一場"},{"type":"link","attrs":{"href":"https:\/\/live.infoq.com\/","title":null,"type":null},"content":[{"type":"text","text":"InfoQ圓桌直播"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"。該直播的參與者包括：Nginx解決方案高級架構師Leif Beaton、獨立的AWS和無服務器顧問"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/theburningmonk","title":null,"type":null},"content":[{"type":"text","text":"Yan Cui"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" 和Skyscanner首席工程師"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/nickywrightson","title":null,"type":null},"content":[{"type":"text","text":"Nicky Wrightson"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" 。大家共同探討了運維的複雜性，以及微服務模型的替代方案。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"“微Web服務”（micro-web-services）一詞最早是由"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/pjr1060","title":null,"type":null},"content":[{"type":"text","text":"Peter Rodgers"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"在2005年的“Web服務前沿大會”（Web Services Edge Conference）上提出的，在當時頗具革命性意義。儘管在2005年SOAP面向服務的架構正處於頂峯，但Rodgers主張的是RESTful服務。Rodgers在演講中，給出了一種良好設計的微Web服務平臺，介紹了它是如何在類UNIX調度和流水線中組合Web和REST服務的底層架構準則，通過面向服務的架構提供靈活性和易用性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"此後歷經六年的創新和思考，在2011年的五月的一次軟件架構研討會上，與會者根據自身所見所爲，冠之以“微服務”一詞。在2012年春季，社區開始使用“微服務”描述此類架構模式。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"對此，"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/boicy","title":null,"type":null},"content":[{"type":"text","text":"James Lewis"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"和"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/fgeorge52","title":null,"type":null},"content":[{"type":"text","text":"Fred George"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"曾做過演講。"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/adrianco","title":null,"type":null},"content":[{"type":"text","text":"Adrian Cockcroft"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"將其稱爲“細粒度面向服務架構”，並在Netflix積極推動此類系統的開發落地。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"微服務這一新領域中的其他先行者還包括"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/samnewman","title":null,"type":null},"content":[{"type":"text","text":"Sam Newman"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"、"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/evanbottcher","title":null,"type":null},"content":[{"type":"text","text":"Evan Bottcher"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"、"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/martinfowler","title":null,"type":null},"content":[{"type":"text","text":"Martin Fowler"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"和"},{"type":"link","attrs":{"href":"https:\/\/twitter.com\/tackers","title":null,"type":null},"content":[{"type":"text","text":"Graham Tackley"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"等人。在微服務得以命名之前，"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.com\/qcon\/","title":null,"type":null},"content":[{"type":"text","text":"最早的介紹可追溯爲Qcon大會的演講"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"隨着DevOps的引入，微服務正大步向前推進。DevOps在團隊構建系統方法方面變得越來越流行，尤其是持續部署的系統。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"但是，微服務也的確需要付出額外的代價。本文將重點關注此類額外成本，以及是否值得權衡考慮微服務。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Wes Reisz：我最喜歡的微服務定義是由Adrian Cockcroft提出的，即“限界上下文（bounded context）中細粒度的面向服務架構”。各位是如何定義微服務的呢？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：這是我這些年來一直在思考的問題。在我投身微服務領域的前三年中，實際上並不瞭解任何DDD的相關知識，我們的架構師也同樣缺少認識。由此，我對微服務產生了一個非常具體的認識，即“最小的、最可獨立部署的代碼”。但這並不正確。我認識到對微服務的定義應該回歸到“限界上下文”的理念。雖然二者並非同一理念，但這一定義確實給出了領域的上下文，也給出了不存在外部依賴項的認知。微服務是完全獨立的。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我也非常認同圍繞限界上下文給出的微服務定義。實際中，我常常會互換使用微服務和限界上下文。當然，我認爲從架構的角度看，Lambda函數滿足所有被認爲是微服務的條件。但一個函數並不能完成所有功能，它只是某個更大系統中的一小部分。爲實現一個系統，需要所有功能都能完美、同步地協同工作。從業務的角度看，只有實際提供的功能，纔是用戶希望得到的。因此在我看來，微服務就是一組獨立完備的職責範圍。某個團隊或是某個人，可以完全具備給定範圍內的所有權，並且可以根據自己的喜好對功能做出考慮、移動和重組。除此之外，一切都應通過消息完成。直接依賴關係應儘可能地少，否則將會創建硬耦合，從而導致在更爲複雜的環境中出現級聯故障。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：微服務自橫空出世以來，歷經八年的發展。各位認爲微服務當前處於技術採納曲線的哪個階段，是早期使用者（early adopt）、早期大衆（early majority）、晚期大衆（late majority）還是落伍者（laggards）？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：出乎意料，事情發展並未背離我一直以來的設想。雖然還有大量早期使用者，但微服務已經越過了早期使用者這一天塹。我認爲用戶正繼續努力向前推進。並非僅是微服務本身，而是涉及微服務的所有一切。用戶需要完全改變架構並轉變思維。而許多組織依然採用的是本地化部署，甚至從未考慮過雲及其伴生技術，也從未考慮過DevOps和持續交付。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"需要注意的是，微服務僅是解決了組織上的問題，並未解決技術上的問題。在選擇微服務方式後，用戶必須能夠適應這種組織上的轉變。我認爲這種轉變會對新使用者產生阻礙，因爲大多數用戶身處非常傳統的組織，運行着非常複雜的單體應用。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我認爲目前依然早期使用者階段。我曾與許多從本地部署甚至是單體應用直接遷移到無服務器的客戶共事，他們必須要去理解微服務，以及如何分解問題域。微服務在監控、調試和可觀察性等方面依然面臨着許多挑戰。當然，這幾年我接觸到越來越多的各行各業公司，它們並未轉向微服務。我意識到，微服務並非適合所有的企業。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz： Nicky，你提到了“組織的”。最初我試圖理解微服務概念時，找到了"},{"type":"link","attrs":{"href":"https:\/\/martinfowler.com\/bliki\/MicroservicePrerequisites.html","title":null,"type":null},"content":[{"type":"text","text":"Martin Fowler的這篇博客文章"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"。我對下面這幅插圖印象深刻：“必須達到如此認識高度，才能運維或運行微服務。” 當前的認識高度如何？比原先更高了，還是更低了？成功運維微服務，需要掌握哪些基礎技能？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/e5\/65\/e506a53cd2c1e0f886d39ea4fc11c965.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：我之前曾提到過，在組織上，我們通過微服務實現分散的更改，從而能夠儘快部署。在公司發展到一定規模時，就會出現問題，團隊和人員希望具有細粒度的自治權。那麼這一規模具體是多大呢？這依然是一個懸而未決的問題。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我認爲從整體上看，某些方面上已經變得更加複雜。對於每個複雜的問題，都已推出了一些簡單的解決方案。如果某個複雜問題存在12種簡單的解決方案，那麼在解決該問題時，我們就必須瞭解全部12種產品。這導致問題永無止境，我們現在有太多太多的工具。爲了整體把握問題，我們必須極大地擴展自己的認知。我認爲圖中那條線依然徘徊在相似的高度，只是需要了解的知識面略爲拓寬了。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我非常贊同Nicky對工具的看法。我當然對DevOps生態系統在工具上的推陳出新毫無興趣，也不喜歡很多人癡迷於具體使用何種工具，可以說是非常反感。就在幾天前，我看到的KubeCon推介活動足足花了一分半鐘的時間介紹Kubernetes集羣中各種用於監視、控制等功能的工具。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Reisz"},{"type":"text","text":"：但我們也必須做出抉擇。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：的確如此。我認爲許多伴生技術本來目的爲了幫助用戶構建微服務架構，但實際上卻使構建微服務變得更加複雜，學習曲線更加陡峭。同時，我認爲我們也正在構建越來越複雜的系統。特別是在無服務器領域，我看到了很多非常有趣而且非常複雜的事件驅動系統。這些系統提出了很多挑戰，即便是以API爲中心的微服務，也可能無法解決跨各部署（例如SNS、Kinesis和DynamoDB流等）進行追蹤這一重要問題。爲解決這些挑戰，一些工具正在不斷改進中。至少從可觀察性方面看，我覺得很有意思的一點是，人們正在爲越來越複雜的問題而構建越來越複雜的解決方案。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz： Leif，你認爲要達到何種高度才能使用微服務？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Leif Beaton"},{"type":"text","text":"：那要看你想要什麼高度？採納微服務具有一定代價，因爲從微服務角度開發應用的思維方式，相比原有的單體應用開發過程在本質上完全不同。相比單體應用，開發人員需要更清楚地定義事物。對於一家小型初創公司，可以從單體應用入手，並觀察其發展。直接使用微服務，往往會有些毫無頭緒（spaghetti soup）。我並不是說必須只有大型企業才能使用微服務。只要事先做好規劃，並釐清應用各部分的範圍，無論對於小微企業還是大廠它都是很好的做法。補充一點，有些應用的確應該維持單體應用。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：我們已經在微服務上遇到了一些問題，其中之一就是Nicky所提到的複雜性。我認爲CNCF（Cloud Native Computing Foundation，雲原生計算基金會）整體上就是一個龐然大物，其中提供了多種多樣的可能選擇。例如，Kubernetes的容器網絡接口（CNI）就存在Canal、Flannel、Weave、Cilium等多種可選的容器聯網方案。複雜性當然是微服務中的一個影響因素。此外還存在哪些挑戰？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Beaton"},{"type":"text","text":"：整體治理是挑戰之一。對有計劃採用微服務的用戶，我們討論過的監視、追蹤等問題是非常重要。因爲應用間的通信並非是在同一應用中運行的內存函數調用，而是與當前系統通信的本地或遠端的網絡調用。監視和追蹤整個應用中的通信，這是至關重要的。否則，就像是戴着眼罩在黑屋子裏抓一隻黑貓。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：Nicky，你談到了組織成熟度。爲什麼說組織成熟度是微服務面對的挑戰之一？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：我認爲組織成熟度將推動團隊的自治並具有所有權。在我看來，成熟度是非常有必要的，因爲我們需要同時對一組微服務或領域採取行動。從組織上講，成熟度意味着我們可擁有該領域。使用微服務，我們無需詢問支付團隊是否可以部署它，因爲已經不再具有這些依賴關係。但從企業文化上講，實現起來並非易事。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：Yan，我們最近探討過編排，也探討了在微服務環境中實現相互通信中面對的一些挑戰。在此你能否介紹一下服務編排方面存在哪些挑戰？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我想我們之間的探討是圍繞使用編制（orchestration）還是編排（choreography）實現業務工作流。其中，編排這一稱法，主要用於以事件驅動爲常態的無服務器領域。某些問題根本不值得付出使用事件驅動架構所導致的代價。因爲在事件驅動架構中，所有的追蹤和監視都是十分困難的。因爲沒有任何一處是受事件源控制的，所以我們無法找到一箇中心點並說“好吧，工作流就是這樣運行的”。系統的工作機制完全存在於某個人的心理模型中。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當然，如果處於某個微服務的限界上下文中，編排也是絕對可行的。這時可使用諸如AWS Step Functions之類的工具所提供的編排引擎，去解決很多問題。也能輕而易舉地解決一些特定類型的問題，例如監視、調試和追蹤。對於支付等關鍵業務工作流，我更喜歡使用 AWS Step Functions等服務去獲取實際的工作流，確保一切都是受控於事件源的。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：你提到了事件驅動架構。我的問題是，事件驅動架構與微服務二者間的關係如何？稍微打斷一下，請你多解釋一下事件驅動與微服務嗎？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我認爲人們原先都是這樣理解微服務的，那就是一種服務通過某個RESTful API調用另一種服務，然後等待響應，因此可以看成是某種“請求-響應”模式。但大家很快就意識到，這種理解實際上存在着一些問題。如果在等待響應時發生失敗，那麼如何操作？恐怕我們得親自去將應用停下來。爲防止發生此類級聯失敗，我們必須做大量額外的工作。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"此外，很多功能並不需要同步實現。事件驅動系統中，如果存在大量同步進程，則應儘量將它們添加到某個事件總線或事件隊列中。例如，我只需處理訂單，而不關心其它操作。我不必去讓促銷代碼系統去生成促銷代碼，然後再讓其他系統執行各自的功能。只需將事件發佈到某個中心化的事件總線上，並顯示“訂單已成功處理”即可。此後，支付系統和促銷代碼系統會去監聽他們各自關心的事件，進而執行相應的功能。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務和事件驅動架構二者是很好的結合。我們已經說過，微服務是獨立自主的。如果某個功能必須持續不斷地對其它系統的API調用做出響應，同時也必須去調用其它系統的API，那麼就會導致功能間更緊密的耦合。而如果每個模塊都在監聽事件，只要某個功能完成就發佈事件，每個模塊就是更加獨立的，進而形成鬆散的耦合。因此，事件驅動是構建微服務的好方法，尤其是在不同服務間的通信方面。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：我們已經討論了組織和複雜性問題，討論了服務編排的相關問題。鑑於存在所有這些問題、所有的可選項，以及微服務所涉及的複雜性，我們是否應該回到構建單體應用上？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Beaton"},{"type":"text","text":"：部分單體應用的確需要繼續保持，不應分解爲微服務。話雖這麼說，但微服務方法提供了很多優點。其中最顯著的，就是對特定組件的工作機制具有更多的控制權，範圍更加限定，並更易於做質量控制。整體而言，也更容易實現應用的質量控制。例如，更新一個搜索系統或支付系統時，不必對整個系統做全面的質量保證，只需聚焦於存在問題的組件即可。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"還有一些不那麼具體或許也不太明顯的好處。面對手頭的問題可以自由選擇任何適用的技術或編程語言，這當然會令開發人員十分開心。相對於單體應用而言，開發人員可以在更大範圍上匹配並組合使用技術。當然，這也意味着招聘適用的人才的難度降低了。如果有兩種等效的工具或編程語言都可以解決特定的問題，那麼適用開發人員的選取範圍也會加倍。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：我認爲並沒有所謂正確或錯誤的答案，不必非此即彼。事實上，公司可以採用適合自身的方式去運營自身的業務領域。問題又回到了組織因素上。是否可以快速部署，快速迭代？有時可能最終雖然開發出了一個看上去很漂亮的微服務系統，但卻無法真正實現所追求的持續部署和持續交付。通常，人們會認爲單體應用能更快完成開發。只要能掌握微服務與單體應用間的通信合約，並儘可能地使用消息傳遞，完全可以同時使用二者。我認爲公司希望着手去採納微服務時，需要非常謹慎。人們總是喜歡嘗試新的事物。我看到了有人不假思索就立刻深深扎入微服務底層，導致團隊最終耗費了95%的時間糾纏於基礎架構問題，只有5%的時間用於開發功能，完全本末倒置了。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：Sam Newman說過類似於“如可能，儘量構建單體應用”的觀點。如果單體應用確實無法滿足需求，那麼再考慮微服務，沒必要無緣無故地引入複雜性。Yan，對此你怎麼看？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我們剛討論了用適合的工具去完成工作。微服務之類的僅僅是工具，每種工具都需要權衡利弊。我們必須根據自身的需求去評判工具，確認是否值得爲工具自身的不足而付出精力。對於一家想要實現快速推進的大型公司，當然希望能儘量降低一個團隊暴露給其他團隊的失敗數量。微服務可以實現團隊間的相互隔離，使得某個服務的宕機不會破壞整個企業的運行，因此非常適用於此類情況。否則，需要安排更多的人彼此相互獨立地在系統上開展工作。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果一個企業中僅有兩三位系統運維人員，可能完全不應考慮微服務，至少在很長一段時期內無需考慮。所有的功能和部署，都可按單體應用的方式完成，除非企業需要進一步擴大規模。Nicky一開始就說過，微服務僅支持解決組織問題，而不是技術問題。很多人通常認爲，一旦需要擴展，就必須使用微服務。事實並非如此。以Supercell爲例，該企業製作的每款遊戲都有過億的日活用戶，一切僅用一個JAR軟件包就能完成。全部僅是一項服務，只需一個JAR，單體應用也是完全可擴展的。事實上，如果對擴展單體應用束手無策，那麼微服務同樣也難以擴展。只有在適當的場景下，微服務纔是很好的工具。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：前面我們一直將微服務和單體應用絕對對立，但二者之間也存在一些中間方式，下面我們討論一下模塊化單體應用。例如，將多個Jar組合在一起，就構成了模塊化單體應用。Yan，你如何看待模塊化單體應用這樣的中間方式？這是一個自然的發展階段，還是應該直接轉向微服務？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：我曾構建過一些頗具規模的遊戲應用後端，服務於大量的用戶。這些後端都是單體應用，在覈心層做了很好的模塊化。如果採用模塊化，可在多個不同級別上實現。無需對部署做切分，尤其適用於必須同時更改所有部署的情況。如果採用微服務，而每次部署更改都必須更改其它幾個微服務，並需同時部署所有更改的微服務，那麼這些微服務並不是真正相互獨立的。我當然認爲不必費力追求實現最純粹的微服務，即絕對不存在共享的數據庫，並且所有內容都是可獨立部署和可擴展的。現實中，實現起來困難重重。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"至少就目前而言，我個人是非常支持採用中間方式的。只要我們理解架構需要實現的特性，就應選擇達成目標的最佳方法。也許決策能夠一步到位，也許首先需要通過採用一些中間方式。我們必須做出務實的決定，否則就會陷於未知的無底洞中，無法從所做的技術決策中脫身。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：我堅信實用性決定設計。有時我們會因爲期望實現完美的工程化，而放棄了對實用性的追求。我看到大批比我年輕的大學畢業生，參與到如此複雜的分佈式系統中，但並未意識到自己是在編寫微服務。他們的方式是從編寫小型模塊化單體應用和微服務入手，然後在其變得愈發笨重之前做拆分。這是一種做法。另一方面，我也看到了一些採用模塊化單體應用的做法。此類做法的問題在於項目的Pull請求會不斷堆積，循環發佈的週期可達一個月。最終，在工程化和實用性上都沒有做好。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：正如Yan所說，使用正確的工具去做正確的事。假設你開發的應用需面對大量的短暫峯值流量，如何使用微服務應對可能僅持續數毫秒的擴容需求？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Beaton"},{"type":"text","text":"：這正是我們的最高追求。我們一直在爲實現超低延遲而努力，我們的客戶涉及所有以超低延遲爲生命線的行業，從醫療保健、金融科技到貿易等。如何應對瞬息萬變的行情？這需要可配置的數據平面，並且內置大量的智能。不僅能夠確定系統是否已啓動並正在運行，而且還需要確定系統中的應用代碼是否能夠及時給出可預測的響應，並逐步淘汰達不到上述要求的代碼。如果考慮着手爲系統匹配適用技術並混合使用，例如我們一直在討論的單體應用與微服務的共存，這時的重中之重在於具有一個非常靈活的數據平面。也許可以引入某種涉及三方的模式，儘快推出一些可替代單體應用部分功能的微服務，諸如此類。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz： Nicky，我們知道Skyscanner使用了數以千計的微服務，你們是如何解決延遲問題的？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：我們在不同區域間保持平衡。一旦發現某各個區域出現了不好的苗頭，我們就會迅速將業務切換到另一區域。我們正遷移到Kubernetes，此前使用的是AWS ECS。但達到規模的快速擴展並非易事。爲高性能地運行負載，需要儘量確保系統整體上具有足夠的彈性。我們也一直在對所有的內容做負載測試。旅遊行業時常會出現一些意想不到的峯值，因此我們正推行的是一種獨特的流量模式。該模式需要經常性地執行負載測試，儘管這完全無法令我工作在舒適區，但能使我們很好地把握問題所在。在其它區域，我們同樣實現了彈性擴展。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：針對如何分解單體應用，我們看過一些演講、論文和技術內容。這些資料宣稱導致分解單體應用並轉到微服務的原因，在於團隊間的不協調或是推進速度等問題。但是我們也看到，諸如Istio又將istiod的架構轉回到更類似於單體應用的事情發生。當出現哪些跡象的時候，我們應該回到單體應用上呢？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：我曾任職英國《金融時報》，或許是因爲並未正確採用DDD，我們加載並堆砌了大量服務。我在其它地方也看到了類似情況，對現有架構做任何更改，都要付出艱辛努力。如果一個爲89個服務提供支持的團隊，面對不斷推出的功能，並且每個功能都具有安全補丁，那麼團隊最終耗費在發佈安全補丁上的時間，要遠高於實際運營業務所用的時間。真實情況是，團隊更多的時間是在維護代碼，而不是開發新的功能。這時我認爲應重新考慮單體應用的合理性，這在我看來就是最可能的跡象。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Beaton"},{"type":"text","text":"：我想再次強調一下Nicky前面說過的，導致錯誤做法中至關重要的一點是：新技術並不一定是更好的。通常並非如此，事實上幾乎完全不會。但有時的確如此，總體而言採用某項技術不能僅僅因爲它是新技術，而是需要有好的理由。如果這項技術能解決你的問題，當然，我贊同。如果僅僅因爲該項技術做了更新換代就採用它，那這個理由不成立。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：最後總結一下。這裏重提Leif的觀點，我們選擇採用某項技術，不能僅僅因爲該項技術是新穎的。我們需要能實際解決問題。Nicky，還有什麼補充嗎？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Wrightson"},{"type":"text","text":"：對於是否採用微服務，我認爲並不存在全有或全無的答案。總存在一些適用微服務的場景。當前好的一點是，採用微服務的試錯代價低，至少可以去嘗試一下是否能採用微服務的一些優點。但不要低估需在組織和文化上付出的成本。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"Reisz：我非常認同Yan強調的“微服務解決的是組織問題，而不是技術問題”。Yan，再補充一下？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Cui"},{"type":"text","text":"：做事的目標，應始終是所期望的業務產出，而非技術本身。並非說技術不重要，而是說我們的目標是創造商業價值，而非爲了技術而做事。以此爲出發點，然後確定最好的做事方式，進而創造最大的商業價值。"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"嘉賓簡介："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"Wes Reisz擔任VMware平臺架構師，是邊緣計算平臺Section的前技術副總。Reisz曾主持QCon舊金山大會，在入職VMware之前曾任全球QCon所有英語大會的產品負責人、HP Enterprise Systems的首席架構師，並在路易斯維爾大學擔任兼職教授達13年。此外，Reisz一直聯合主持"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.com\/podcasts\/","title":null,"type":null},"content":[{"type":"text","text":"InfoQ Podcast"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"Leif Beaton是位於愛爾蘭Cork市的NGINX公司的高級解決方案架構師。他具有20年的IT部門工作經驗，已形成包括安全性、網絡、軟硬件體系架構以及開發在內的多元化背景。Leif日常工作是與NGINX客戶互動，爲將客戶需求轉換爲現代架構提供幫助。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"Yan Cui是一位經驗豐富的工程師，自2009年以來一直任職於AWS。他是銀行、電子商務、體育流媒體和移動遊戲等多個行業的架構師和首席開發人員。Cui以其在Medium上的無服務器文章以及個人博客"},{"type":"link","attrs":{"href":"https:\/\/theburningmonk.com\/","title":null,"type":null},"content":[{"type":"text","text":"theburningmonk.com"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"而聞名。他的部分工作已納入AWS無服務器優選架構白皮書（Serverless Well Architected）。他具備C＃、F＃、Scala、Node.js和Erlang等語言的專業編程能力。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"Nicky Wrightson具有豐富的大規模雲原生架構交付經驗。她曾任職《金融時報》，現就職於Skyscanner。她專注於推動可操作性爲大型分佈式系統開發的頭等問題。運維Skyscanner的超大規模數據平臺，意味着在整體解決一整套新問題的同時，仍需要盡力實現可操作性、成本效益和可維護性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}},{"type":"strong"}],"text":"原文鏈接："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.com\/articles\/reviewing-microservices-architecture-operational-complexity\/","title":null,"type":null},"content":[{"type":"text","text":"Reviewing the Microservices Architecture: Impacts, Operational Complexity, and Alternatives"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]}]}]}