我們的很多客戶都在關注微服務，而我們經常被問到的一個流行問題是“你看到微服務最大的錯誤是什麼？”。 我們已經看到了很多這種架構模式的好東西，但我們也看到了一些反覆出現的問題和反模式。 去年，我們的姐妹公司OpenCredo的首席技術官Tareq Abedrabbo創建了一個題為“微軟服務的七大罪”的精彩演講（和博客文章）。 Tareq和我就他發現的反模式進行了一些引人入勝的討論，這促使我創建了一個衍生產品，結合了Tareq的想法和幫助客戶實現基於微服務的架構的經驗。
介紹微服務的致命罪（redux）
我很幸運能夠在QCon New York和Devoxx UK上發表這個新演講，我很想分享演示文稿的概述幻燈片，以便開始討論。 這是我的“七個致命的微服務罪”：
這些反模式究竟是什麼？
讓我們深入研究這七種反模式並提供更多解釋：
1. LUST - 使用最新最好的技術(Using the latest and greatest tech)
在Container Solutions，我們當然不會羞於使用最新和最好的技術 - 事實上，這是我們的理念的核心。但是，我們總是與客戶討論如何使用最合適的技術來實現他們的目標，問題或用例。我們是Docker，Mesos和Terraform等技術的堅定支持者，我們知道它們可以為IT團隊帶來的價值，但我們努力與組織合作，幫助他們制定戰略並推動支持應用程序所需的變革這項創新技術。
2. GLUTTONY - 過多的通信協議（Excessive communication protocols）
在技術選擇的地方，我們經常會在大型組織中看到很多變化，而對於微服務，這種變化通常可以在通信協議中找到。這種反模式的解決方案是瞭解你的選擇 - HTTP，ProtoBuffs，Thrift，AMQP，MQTT等 - 但是試圖標準化使用一個同步和一個異步協議 - “不要金板，但要知道你的選擇”
3. GREED - 您所有的服務都屬於我們(All your service are belong to us)
“貪婪”的反模式圍繞著對引入微服務的組織，人員和文化影響的討論（暗示 - 這比大多數人欣賞的更大！）。我在OpenCredo博客文章“微服務背後的業務：探索組織，架構和運營挑戰”中寫了更多關於此的內容
4. SLOTH - 創建分佈式但體 (Creating a distributed monolith）
在實現微服務時很容易變得懶惰，只要你不能獨立部署服務，你所擁有的就是分佈式整體。下面的幻燈片包含幾個參考和鏈接，以避免這種情況進行探索，但核心原則是要注意您的服務邊界和API。當我說'留意'時，我真的暗示你的設計和合同必須是可以自動驗證和強制執行的！
5. WRATH - 當壞事發生時爆炸(Blowing up when bad things happen)
絕大多數微服務系統將作為分佈式系統運行，因此我們必須尊重這一點（作為開發人員和運營商）。作為開發人員，我們需要採取防禦性編碼，並利用容錯模式，例如超時，重試，斷路器和隔板。邁克爾·尼加德的優秀“發佈它！”一書應該是強制閱讀，訪問Netflix OSS工具Github存儲庫也應如此！作為運營商，我們需要接受共享理解和責任的“DevOps”心態，並花費大量時間開發和使用工具來支持我們的角色。 Adrian Cockcroft最近就一些關於監控微服務和容器的挑戰提出了一些很好的指示。
6. ENVY - 共享的單域謬誤（The shared single domain fallacy)
對於整體而言，開發單個共享域模型的概念通常是一個關鍵模式，因為這將在整個代碼庫中使用。但是，通過微服務，“有界上下文”的域驅動設計（DDD）原則已經變得流行，並支持我們正確封裝我們的域模型
7.PRIDE - 在瞬間的世界中進行測試（Testing in the world of transience）
使用微服務進行測試很難 - 這只是一個事實。然而，艱難並不意味著不可能，因此我們需要創建新的工具和流程來支持快速變化，動盪和瞬態的測試。在我的演講中，我引用了Toby Clemson在分享他的“微服務架構中的測試策略”方面所做的出色工作，但仍有許多工作要做。一段時間以來一直在創建微服務的許多組織都在爭論測試微服務的唯一有效方法是生產，因為在合成的臨時環境中無法預測系統的緊急行為。
閱讀更多 智能時刻 的文章
