所以，歡迎回到微服務模式和實踐跟蹤。所以我們有所有的揚聲器，除了一個，但這很酷;談談 - 是的。來吧。我們有所有發言人，這很棒。很棒，我們五個人。非常非正式，我沒有正確 - 你知道，這是你想聽到的。所以我想我們會試著弄清楚如何居中 - 為你和我們準備一個麥克風。太棒了，我們有兩個，我可以成為賽跑者，也許我會請一位志願者來幫助我。我會保留這個。很酷，火了。
在進行綠色部署時，如何管理數據？因此，例如，您可能有一個寫入新記錄的版本，舊版本無法理解，舊版本如何知道它不是錯誤，它實際上是真實數據？
Randy Shoup：我有一個答案，但你為什麼不首先嚐試它。
Roopa Tangirala：所以當你在Netflix上進行更改時，你可以做到這一點，它是無狀態的，這不是問題。但是當你對Cassandra進行更改時，它就是無模式的。因此，當您添加新列或更改架構時，您不一定需要執行DDL來更改架構。您可以直接插入新數據集或新列系列新列。這是一種方式。
另一方面，如果他們幫助從一個列族遷移到另一個列，我們幫助他們構建工具，我們擁有客戶端庫，所以我們可以幫助他們寫入舊的和新的，我們有像fork這樣的工具升降機，有助於從源頭升級到目的地，但並非所有部署都需要在我們移動數據的地方進行更改，至少這是Netflix所具有的。
Chris Richardson：我想補充一下，所以為了減少部署時間，限制你可以在數據庫級別進行的各種更改。例如，您可以添加列，但不能只刪除列。因此，它需要仔細進行更改，並將數據庫架構更改與零停機時間部署分離。
Randy Shoup：是的，不要做你剛才說的話。甚至不開玩笑。所以你所做的就是破壞了界面。您進行了非向後兼容的數據更改，並將其公開給其他人，並且您以某種方式執行此操作，例如，在次要版本之間。因此，如果人們熟悉語義版本控制，那麼您剛才描述的是非向後兼容的主要版本更改。我在說什麼才有意義？我們曾經以這種形式生成數據，現在我們以這種非向後兼容的其他形式生成數據。
所以，不要這樣做。你能做的就是克里斯所說的，也就是說 - 我們可以詳細談談你想要做出的改變。有很多方法可以進行向後兼容的更改。您可以添加一個可選字段 - 遺憾的是，我們需要更詳細地討論它。但是，是的，您知道，作為服務所有者，您的主要工作是永遠不會打破使用您服務的人。 o永遠不允許您破壞客戶，而客戶是您的活動的消費者。從概念上講，這有意義嗎？
是啊。好的，很酷。在後面的方式。實際上，我會先到這裡，然後我會到這裡來。
因此，我們發現的一件事是決定微服務的邊界上下文。它可能就像，好吧，我們訂單，然後可能有五種類型的訂單，現在我們知道微服務是一段時間後的整體。你如何決定邊界背景，以便在幾層之後它足夠好？
Louis Ryan：我的意思是，大多數情況下，您的開發實踐可能會在您的開發決策中得到通知，而不是您從一開始就會嘗試猜測的任何嚴格的語義。我的意思是，我傾向於認為微服務是出現在需要解耦的緊急模式。我沒有微服務水準。它是 - 所以它是，你需要努力。但通常，您知道，解耦在開發團隊的邊界上工作得很好，或者在開發團隊中負責。這就是我要開始的地方。
Chris Richardson：是的，我想說這是最困難的問題之一，而且它實際上並不是微服務特有的。你知道，這基本上是另一種重新措辭的方式，就像我的模塊的邊界一樣，對吧？我認為，挑選模塊邊界很困難。並且，遺憾的是，沒有任何一種機械過程，如果你應用它，你會想出一套完美的模塊，一些模塊邊界。因此，就服務而言，它就像是，大多數是圍繞特定的業務對象組織的，如訂單管理和客戶管理等。但這是你的第一個猜測，你繼續這樣做，如果你以後發現某些服務太大了，那麼希望在那一點上，該模塊的兩個內部部分之間有足夠的邊界，這樣你就可以分開它以一種有意義的方式。
然後，就像路易斯所說的那樣，服務點就是讓一小群開發人員能夠快速安全地交付。而且，就像 - 如果一個模塊，你知道，如果一個服務變得太大，這真的意味著正在開發它的團隊已經變得太大了，並且它們被通信開銷所拖累。所以你有點想要分裂團隊，你想要拆分代碼，這樣他們就可以重新成為一個小而敏捷的團隊。
Randy Shoup：我還有一個想法，然後我會回到前一個問題的傢伙。所以我斷言的其中一件事是因為我相信，如果你是，你知道，五人初創公司，你可能不想從微服務開始。部分原因是它仍然有點複雜，構建分佈式系統可能要複雜得多，每個人的問題都圍繞著複雜的事情。當你小的時候，你想開始做一些不同的事情。另一部分是你想要了解你的域並在你做微服務之前以合理的方式分解它。那有意義嗎？微服務只是域的分解的物理表現。所以我發現，因為我已經嘗試過多次嘗試並且未能做到這一點，我第一次解決了一個新問題並弄清楚域名的分解是什麼 - 我一直搞亂它。我有一頭白髮/沒有頭髮，我已經這樣做了一段時間。因此，當你很小的時候，可能不會從微服務開始的規則有兩個罕見的例外。
首先，如果您的MVP，如果您的最低價值產品需要規模。因此，如果您正在構建Heroku競爭對手，例如，您正在構建互聯網基礎架構，那麼您可以從一開始就進行擴展。這是一個要求。第二個是，如果你瞭解你的領域超級好。那裡的例子，我能想到的，一個很好的例子就是建立新銀行的人，對吧？所以來自巴西的Nubank昨天發表了第一次談話，他們在“你總是想知道的架構”中，開始使用微服務。為什麼？因為你在過去50年中所知道的銀行的組成，因為銀行的組成部分真的很容易理解。但對於我們其他人來說，我們並不瞭解這個領域，這就是為什麼這是一個如此重要的問題。
我們知道我們是一個單一的應用程序，我們知道我們想要獲得業務上下文類型的服務。但是，這條線在哪裡繪製 - 它是產品級別，API級別，微服務水平？那條線在哪裡？這感覺恰到好處嗎？
Rafael Schloming：當然。是的。這是一個 - 這是一個很難的問題，但我認為其中一種有助於思考的方法實際上是蘭迪先前所說的，不考慮微服務的大小，代碼行，考慮範圍，以及如何定義範圍？好吧，你需要了解你想要達到的高水平，一兩句話。所以我總是喜歡思考，你知道，這實際上是關於你如何知道API是否完成的問題。
它實際上是服務用戶與提供該服務的團隊之間的協商。您需要跟蹤使用情況，如果您的用戶滿意，那麼您就完成了。而且，是的，假設您不必每五分鐘更換一次。所以，是的。所以它 - 從框架的角度思考，瞭解服務的用戶是誰，以及從那裡開始，真的很有幫助。而且，從這個角度來看，你可以嘗試很多不同類型的API，這些API可以提供相同的任務，並找出你需要的東西。而且，您可以再次跟蹤您在創建用戶方面的成功程度，以便在您艱難的設計空間中進行迭代測量。這就是我要說的。
Randy Shoup：所以這是一個輕微的翻轉響應，但我並不是以任何激進的方式表達它。你們知道嗎，你們建立了一個類，比如Java中的一個語言類還是其他類？不，你是如何建立的，你怎麼知道課程的範圍是什麼？這是一個設計的東西，課程是一個單一的責任;我們試圖使界面最小化，儘量不要聊天。我們這樣問的原因不是讓你當場，而且為我工作的人現在正在笑：這是我和我的團隊多次做過的事情，這對我來說是合法的。說。男人，微服務，我們之前從未建立過服務。您是否構建了類，是否構建了類似於特定的界面，您知道的語言環境是什麼？哦，是的，我們完全做到了。你怎麼弄清楚進出的是什麼？這很簡單，我們會隨著時間的推移對其進行改進。
這就是答案;你知道的不僅僅是如何設計服務。如果您知道如何設計類，那麼在大多數情況下，您知道如何設計服務。唯一的一部分是認識到你不能像服務那樣對你的過程中正在進行的過程中使用的東西。那有意義嗎？但是，除此之外，你已經知道了。如果您知道如何構建應用程序，您完全按照徽章上的人員進行操作，那麼您已經瞭解了比構建服務更多的知識。
克里斯理查森：是的，分解適用於許多層面。從某種意義上說，您可以分解方法和類以及包，模塊，因此微服務只是這種層次結構中的另一個層次。我要補充的一點是，我認為微服務也與團隊結構有著這種重要的關係。就像對我來說，我認為微服務有兩種模式。有這種超細粒度模型，這是每個開發人員的一項服務，似乎在一些公司正在發生。對？或者，當你擁有成千上萬的服務時，我的意思是，那種數量級。另一種思考服務的方式是，足夠小的引用“應用程序”，團隊可以保持敏捷和敏捷。
這就是一種 - 這是一種更為粗糙的微服務穀物模型。這會影響分解。
Louis Ryan：所以，是的，我的意思是，我認為這可能是房間裡很多人的常見問題，他們有一個他們想刮鬍子的單塊犛牛，這是完全沒問題的。在您認為剃鬚增加價值的地方開始剃鬚，並在您沒有獲得更多價值的地方停止剃鬚。如果它正在做它應該做的事情，那麼可以擁有一塊巨石。我知道這可能是異端邪說，但如果它正在做它應該做的事情。如果不是，請刮鬍子，然後迭代。
Randy Shoup：對不起，這是休息時的一個很好的問題。我會在此之後閉嘴。優秀的問題或多或少，嘿，微服務值得嗎？對我們大多數人來說，答案可能不是，對吧？這是 - 再次，正如我在演講中試圖說的那樣，它是.1％，0.01％達到了真正的大，絕對你 - 谷歌，亞馬遜，Netflix，StitchFix沒有辦法沒有微服務。但微服務，如果你沒有巨大的負載，堅持使用巨石就可以了。就像這一點，我們什麼時候應該堅持使用微服務？那麼，你什麼時候應該，你什麼時候不能獨立擴展，什麼時候放慢速度，什麼時候會以不同的速度發展？那是你必須擴展的牆。但如果你感到高興，我很高興 - 我們會這樣說。
Chris Richardson：我想補充一點，比如，你知道，如果你的開發速度不是它需要的地方，我會在切換到微服務之前開始審查你的開發實踐。因此，例如，如果您沒有徹底進行自動化測試，我認為根據源實驗室報告，可能有70％以上的組織沒有 - 完全不接受自動化測試。所以，如果你是其中之一，那就先做好。然後，你知道，一旦掌握了這一點並且你真的能夠儘可能地自動化，那麼考慮一下微服務架構。有點像，在跑步之前嘗試跑步或走路。
Rafael Schloming：是的，這是一個很好的觀點。對不起，這是一個很好的觀點，而且一件好事只是，它不需要超重，就是追蹤你花時間的地方。如果您正在進行大量的手動測試，這會減慢您的速度，那麼您不一定會在日常工作中考慮這一點。並且，你知道，如果你花費大量時間與你的巨石的特定區域搏鬥，也許那時你應該開始剃掉你特定的犛牛。
Louis Ryan：所以我認為蘭迪給出了幾個你可能想要這樣做的例子，規模是業內引用的更明顯的例子。我認為還有其他原因;安全性是你為什麼想要削減你的巨石的一個重要原因，因為你有兩件事不應該在同一個信任域中粘在一起，這是一個很重要的原因。他的開發經驗顯然是一個，釋放速度是一個大問題。因此，有多種原因，你知道你的域名，你知道你的域名正在發生什麼，你應該能夠推斷出這些決定的原因。
克里斯理查森：是的，從我的角度來看，它很有意思。我認為微服務主要是一種解決複雜性而不是擴展的方法。縮放，我的意思是，顯然，這是一種擴展方式，但複雜性是第一位的。
是的，我有一個問題 - 你們可以評論團隊用於獲得微服務的模式嗎？它們是從真正重要的中間開始的，它是一個重要的對象，或者我是在它沒有產生重大影響的一側做的，我可以在現有應用程序上打一個休息API並調用它微服務？
Chris Richardson嗯，你知道，如果你是 - 如果你的年度獎金取決於擁有微服務......但是，我只是開個玩笑。但是，不，我的意思是，微服務 - 這個術語微服務真的會被濫用，對嗎？就像這個動議一樣，我可以 - 我可以使用一個微服務，這是一種錯誤的概念，我的意思是，從我的角度來看。微服務是微服務架構的一小部分，微架構架構是應用程序的架構風格;這就是擁有一個系統。
還有一件事要考慮，所以如果你有這個巨大的巨石，如果有一部分是非常非常積極的發展，另一部分是你永遠不會觸及的，那麼如果你想把它們拿出來，要知道，如果要構建微服務或服務，請提取應用程序中經常更改的部分。因為那會給你帶來最大的收穫。
你知道，如果你考慮一下你的整體，那就是發展緩慢，你從微服務中提取出來的一切都在快速部署，快速部署和所有這些。因此，您希望將精力投入那些真正有效的領域。
Randy Shoup：所以，一如既往，我有想法。所以這是我的想法。這些步驟，所以我將從整體到微服務進行一些架構改變。因此，我想證明這種千禧一代的微服務方式實際上是一件事，並且會在我們的環境中發揮作用。所以步驟零是做一個飛行員。所以我想考慮的方式 - 讓我們採取對我們的業務至關重要的縱向，端到端的實際體驗，例如，我不知道您的業務是什麼。讓我們想象一下，你有一些對用戶真正重要的東西，並以一種新的方式構建它。所以它可以合法地成為一種新的東西，你將建立一種新的方式，或重建一種以新的方式存在的舊東西。無論哪種方式，採取垂直的端到端事物並以現在的方式構建它。為什麼？
我們正在建立一個試點，我們想要降低它的風險，我們想要學習所有我們不瞭解微服務的事情。我們將其作為試點而不是構建整個基礎架構。我們提供垂直的端到端用戶體驗，因為我們希望能夠專注於某些特定的事情，並告訴我們我們需要做什麼，不需要做什麼。如果我們選擇無關緊要的東西，我們就不知道里面或外面是什麼。如果我們選擇實際有用的東西，那麼這將有助於我們專注於完成工作所需的最小事情。我們選擇有用的東西的另一個原因是，如果這不起作用，最壞的情況是，我們為客戶提供了一些價值。
那有意義嗎？這就是步驟零，那個飛行員。既然這個試點成功了，我們已經學會了所有關於如何以新的方式做事的事情，我們將其稱為微服務，現在步驟1-N採取的是投資回報最高的事情，不是最簡單的事情，不一定是最艱難的事情，而是投資回報最高的事情，我們首先將這些轉變為新的方式。
所以這有點，我打算，比如，你知道，消費者，我想要過去所有人們正在發表的評論。因此，考慮一下真正快速變化的領域，可能具有最高投資回報率，或者收入最高的網站部分，這將是一個有利於更快地獲得更多收入的地方。這有意義嗎？你做了飛行員，你冒了風險，然後你做了最高的投資回報率，然後是第二和第三高，你繼續前進，直到你沒有耐心或資源。如果你在完成之前就用盡了，那很酷，因為仍然存在的巨石不是你關心的東西。沒有投資回報率，它沒有超出我們需要的範圍，你知道，有動力將其轉換為微服務。
這正是Ebay所做的。因此，當Ebay-來到這裡的人聽過我之前關於Ebay的談話時，有了這個怪物C ++巨石，他們把它分解成許多用Java編寫的應用程序。所以它不是微服務，但原理是一樣的。一旦他們做了試驗並且他們確信Java可以在Ebay基礎設施中使用技能和人員以及所有類型的東西工作，那麼他們基本上對網站進行反向排序，比如，哪些 - 他們把網頁打開了該網站並通過收入貢獻對其進行逆向排序。所以他們首先轉換的最高收入頁面，並不是因為他們非常想要承擔最大的風險，但是，如果他們沒有耐心，金錢或資源，他們首先做了最有價值的事情。甚至在我2011年離開那裡的時候，他們已經在2000年或2002年開始了重新架構，或類似的東西，他們大部分已經完成，我想說2007年或2006年。它花了一段時間，並且即使我在2011年離開後，仍然存在V2上的東西，比如C ++ monolith體系結構，但它們是沒有人使用過的東西;他們很簡單，他們沒有改變。所以沒有投資回報率將其轉換為新的方式。你去吧
我的問題是關於微服務之間的通信。所以我們談論有事件，所以服務A談到服務B-順便說一下我在這裡。那麼，對於關鍵業務服務，如信用卡處理，並說我們看到Kafka或其他經紀人的大量模式，一旦我收到 - 一旦消息在經紀人中，那麼有辦法恢復，或重試。但是，建議確保信用處理服務確實發佈事件的建議是什麼？我看到，例如，Kafka現在有Kafka連接，並且對於每個數據庫提交或每個數據庫事務，它都可以直接發佈到Kafka。如果業務對象與數據庫中的業務對象不同，該怎麼辦？所以我想在這裡得到你的想法。
Roopa Tangirala：所以在服務方面，擁有真相的來源，因此每個應用服務都是其所服務數據的真實來源。因此，對於付款處理，在Netflix的情況下，他們不使用Kafka，他們有不同的付款工具。他們使用交易數據工具進行支付處理。但基本上這個想法是每個服務都擁有它負責的數據，而且它是真相的來源。對？
所以，這就是交互發生的方式，比如，其他服務會詢問服務而不是直接複製數據集或在後端有多個副本。
克里斯理查森：它有幾個部分。一種是在數據發生變化時以原子方式發佈消息。因此，從概念上講，更新數據庫和發佈消息涉及到一個事務。所以，我將在我的演講中介紹的其中一件事情，接下來 - 顯然軌道主持人不會，那裡，因為他將會發表不同的演講。所以無論如何，圍繞事務性消息傳遞有一個完整的東西，這是一種方式，這是一個非常有趣的話題。然後，它最終可靠地發佈到消息代理。
那就是，你知道，第一步。然後是第二步，您的消息代理必須可靠。這就是蘭迪至少在交付時所談論的內容。然後是消費者端，您需要冪等事件或消息處理來確保正確的語義，並且包括跟蹤您看到的所有消息ID。所以這是一個完整複雜的話題，我將在今天下午晚些時候討論，有些我會在我的書中介紹微服務模式，無恥插件。
Rafael Schloming：我只是想參考一下，你知道，這就像設計課程一樣，這個所有權領域是 - 所有權和整個溝通領域，以及整個事件。這是您轉移某些數據所有權的責任。這就是微服務與設計類最不同的地方，或者他們與設計傳統類API最不同的領域之一，因為你不必擔心，你沒有這樣，有點，您知道，類層次結構的上下文中的數據的位置。因此，這是一個值得關注的事情。
我想，只是一個後續問題，在最後一個問題上有點像燕尾。與事件驅動的體系結構相關，您是否可以從面板上分享您對使用值傳遞，通過引用這些消息以及消費者如何處理該消息的想法，以及您對如何處理訂單的想法那些？
Louis Ryan：我可以提出我的看法，這也可能在某些方面有些異議，但這受到了Google規模的影響。我們大多不這樣做。大多數服務通信服務都不通過代理進行協調。我們使用諸如重試和網絡級別之類的東西來通過不打擊存儲來擴展。你知道，這又是一個規模問題。如果存儲中的持久隊列為您提供了大規模應用程序級別所需的可靠性，那麼您應該使用它。我認為，在某些規模上，某些模式可能會變得更加有限，特別是取決於等待的工作量。對？因此，我們並不反對這種模式，我們確實使用了這種模式，並且我們使用封裝在API後面的模式，並明確分配責任。但是，在大多數情況下，我們不會這樣做。我們不做會合或那種類型的事情。
克里斯理查森：我不相信你不使用卡夫卡。
Louis Ryan：我們看起來像這樣的東西。
克里斯理查森：不，這是個玩笑。但卡夫卡看起來很時髦。
路易斯瑞恩：所以我聽到了。
克里斯理查森：無論是對還是錯。所以，對我來說，所以當你 - 所以當我們談論事件時，在我的大腦中，我所翻譯的是域事件，這是域驅動設計的概念。所以，如果你去閱讀其中一本DDD書籍，你知道，他們就像Vaughn Veron或Vernon Vaughn一樣實施DDD，它有一章關於域名事件，包括你在活動中應該擁有的東西，你可以選擇。如果創建了訂單，您可以發佈訂單ID，但這對消費者沒用，因為他們必須獲得訂單。所以有事件豐富的概念，它說放置對事件中的消費者有用的有用數據。當您發佈訂單創建的事件時，請在其中填寫訂單詳細信息。當您使用事件源時，您的事件是域對象的存儲機制，除了將必要的數據放在那裡之外別無選擇。
然後你的另一點是訂購，是的。我認為有序，至少一次，域事件的交付真的非常非常重要，因為如果它們無序到達，那麼你將會有非常奇怪的行為。我的意思是，可能還有其他情況你不關心交付，你可以發佈/分發一個事件，但訂購通常非常重要。
Randy Shoup：你問過這個問題，當我多次得到這個東西時，我是如何處理事件傳遞的，我該如何處理事件排序？因此，在事件過程中或跨分佈式系統的消息傳遞中沒有的那些事情或那些問題。是的，我想我們已經提供了部分答案，我想我會說，我的意思是，我一直威脅要做這個活動大師班，它可以 - 每次我都談論這個問題。你去，玩得很好。所以，是的。讓我們來看看。
因此，再次，在交付時，您最多可以擁有一次，或至少一次。如果您關心自己的活動，至少需要一次。那就是失敗;我送了兩次，三次，N次。最多一次基本上用於記錄數據，那些失敗的東西你想放棄它。域事件不屬於該類別，但記錄的是事物。這是第一件事，然後你有多次，然後你必須是冪等的，客戶端必須多次交叉引用。如果您在夜間通過這些問題（無衝突的複製數據類型）保持警惕，則應該考慮CRDT。
然後就事件排序而言，A，處理它的幾種方法之一。你可以處理公共汽車的訂購，發誓，這不是很好。處理它的另一種方法是讓事件成為發生事件的通知，然後你去回讀為當前狀態產生事件的服務。這些都是解決問題的合法方式，並考慮這些答案 - 蘭迪的做法與克里斯的方式相比，路易斯的做法。想想這個問題有一個解決方案的空間，並且不要通過推理第一原則來解決它。我試圖解決它，說這很容易 - 不，不是。幾十年來，很多人已經對此做了很多考慮。
Refactoring Fame的Martin Fowler給出了一個精彩的主題演講，今年在芝加哥GoTo舉辦的事件驅動架構上，這是18分鐘。而且，他以非常好的方式，非常清楚，他通過事件的利弊作為通知，以及隨身攜帶數據的事件，事件採購等。這非常值得您18分鐘結賬。
路易斯瑞恩：我想提一個警示故事，或者不一定是一個比喻，但我早些時候就超級大國發表了一個話題，提防超級大國。事件經紀人是超級大國。當你把事情排成隊伍時要小心，你不知道他們將在何處或如何出來，或者他們會出來。如果您不知道這些問題的答案，那麼在您回答問題之前，不應將這些問題放入隊列中。如果您有關心的數據或您的用戶關心的數據，您需要在某種程度上推理這些事情。事件經紀人已被提出作為一種方法來讓操作員控制，以便他們可以回答這些問題，並對此進行驗證。好的？
來自這裡的問題，再次。讓我們來看看一些進化。所以最初當網絡開始時，每個人都在編寫有趣的應用程序，然後是Rails和MVC以及Rust，然後人們就開始編寫這些內容，然後我們就有了整體規模讓我們放慢速度。現在微服務是流行語。你不能走進公司，也不能聽到微服務這個詞。所以，如果你退一步說，在微服務趨勢飽和之後，你預見會發生什麼？接下來是什麼？ Microfunctions？
Louis Ryan：那不是已經發生了嗎？
所以我想退一步看看，從不同的縮小鏡頭看下一步是什麼，你知道什麼 - 你認為會發生什麼？
Randy Shoup：元回答是看看谷歌，亞馬遜和Netflix現在正在做什麼。如果你提出這個問題，那就沒有羞恥，如果你提出這些問題，我會翻轉，你就要落後於這些人，這是件好事。您無需推理，您可以查看這些較大的架構共享的內容。
克里斯理查森：是的，這是一個有趣的。在某種程度上，有一個限制，超出該限制，分解模塊沒有意義，對吧？所以，如果你回到面向對象設計中的一些經典工作，即常見的閉包原則，那些因同樣原因而改變的東西應該打包在一起。這意味著，如果將一個包分解為兩個包，並且實際上，您已將這個業務概念拆分為這兩個包，那麼無論何時該業務概念發生更改，您都要更改這兩個包。所以你將看到這個鎖定步驟。
當然，對我而言，微服務架構中的反模式中存在一種模式，即分佈式整體，您實際上就是在那裡同時發佈多個服務。從邏輯的角度來看，這是一個部分。
然後，你知道，從簡單的技術角度來看，你可以肯定地說，在部署方面，我們的部署單位已經越來越多，它的重量越來越輕，而且越來越短暫。所以，10年前，如果你想部署一些東西，你必須得到一臺物理機器，或15年前。而現在你只需在AWS上部署一個lambda，就像 - 並且在如此短的時間內，這是我們如何部署事物的根本轉變。所以，對我來說，這是一種巨大的趨勢。甚至從設計的角度來看，您必須牢記這種常見的封閉原則。
Rafael Schloming：有一種方式我喜歡思考這個問題，這個問題與此非常相似，但是從不同的角度來看，這就是考慮到你需要多少人才能完成某些事情的趨勢。如果你看一下從整體到微服務的轉變，通過組織視角，這就像分工的轉變，對嗎？你正在接受一個團隊，一個由數千人組成的工程團隊的輸出，你從根本上將這項工作的成果以不同的方式組合成一個連貫的洞。如果你看一下，你就會知道，10年前，提供給定服務所需的團隊規模是多少。我的意思是，今天，一個少年可以在週末從父母的地下室做同樣的事情。所以，至少接近於此。
所以我認為這個限制真的歸結為，好吧，對，那個團隊規模，你知道嗎，你能有效地停止收縮的重點是什麼？這是一個單一的開發人員可以吸收和完成多少，直到你投入像AI這樣的東西，我相信人們現在正在做什麼？
克里斯理查森：我可以回應嗎？有趣的是，我不知道單個開發人員編寫代碼的效率是否有所提高。對？喜歡，編寫和創建全新的代碼。所以我回頭看，有些事情發生了變化，對吧？就像機器變得越來越快，如果我們陷入困境，就會有Google或Stack Overflow。然後就是所有這些開源軟件，所以我們可以快速組裝一堆庫，如果我們遇到困難，我們就會得到答案。但是，就從頭開始編寫代碼而言，我覺得這是一個單獨的開發人員，以某種方式混淆，摸不著頭腦。而且，如果這沒有改變，我們在這方面沒有摩爾定律用於軟件開發。
Louis Ryan：所以如果我們處於預測領域，你知道，我認為有些答案是在供應商的攤位之外。越來越多的代碼在同一個網絡上運行，我並不是你的意思，我同時也意味著你們所有人。你們都把你的代碼放到雲供應商那裡;這個房間裡的其他人比以前更加本地化了。所以我們有這種有趣的網絡效應。微服務不僅僅是您構建服務的一種方式。它也是您使用其他人為您構建的服務的一種方式。
所以我認為，當我看到那裡，我看到供應商銷售某些類型的服務時，讓我感到震驚的是，它們是大型供應商過去銷售的小型版本。當我看到它時，我看著APM空間。當有更多的微型投影機時，你會看到這種趨勢繼續下去;會有更多的市場可以幫助你獲得有趣的東西。就像有人詢問地理位置一樣。你可以購買它作為一項服務。這是一個小小的服務;它在API方面做得很少，而在後端方面卻有很大的數量。所以這是我們可能期待看到的一件事。
Rafael Schloming：我認為這兩個答案引發了一千個，抱歉，這引發了很多。我不認為開發人員編寫了一千行代碼，但是他們的工作效率更高，因為他們想出瞭如何組裝很多東西，以及你剛剛提到的其他東西，或者你剛剛提到的是一個例子。 ，有點，其他東西要組裝的市場。
因此，當我登錄到Netflix這樣的應用程序時，它是一種非常無摩擦的用戶體驗，你知道，我登錄一次，我沒有意識到我正在登錄微服務以獲取我的用戶配置文件，然後我沒有登錄或重新體驗 - 我的客戶歷史等等。那麼，在微服務架構中，您如何維護這種無摩擦的UI？因為我們大多數人都在編寫跨越多個服務的應用程序，但從用戶的角度來看，它實際上只是一件事，他們試圖去的一個應用程序。那麼我如何保持無法共享的架構的優勢，我可以獨立部署，我不會在它們之間創建這些依賴關係，但與此同時，我保持一種無摩擦，統一的用戶體驗，相同的外觀和感覺？謝謝。
Roopa Tangirala：當然。你好。是的。因此，看待它的方式就是，微服務層中也有不同的層。所以有前端，它佔用了所有用戶流量，然後我們有中間層和後端層，這是您的會員資格和為您提供該數據集的所有酷服務。因此，就UI集成而言，這些服務之間存在很多交互，但是，在任何給定時間，真相的來源只是一種服務，對吧？
所以，在與UI的交互方面，我們所有的UI團隊，我都不是 - 我對這個UI層沒有太多的見解。但是他們在確保這些微服務之間的所有交互以及他們在UI中獲得的結果是無縫的方面做得很好。幕後有很多工作要做，但每個微服務都與另一個沒有關係。這樣，您就知道要調用哪個服務。因此，雖然有很多互動，但你也有後備。因此，從UI的角度來看，您沒有看到您的體驗有所降低。如果您無法獲得要觀看的個性化電影列表，那麼如果您無法使用該服務，那麼他們可能會讓您回到後備頁面。所以你可能不會遇到降級服務;你並不認為自己沒有看到活躍的電影列表，但通過這項服務，它可以為您提供後備體驗。
大。所以我們沒時間了。這是一個很棒的問題，非常感謝你。
閱讀更多 智能時刻 的文章
