知識星球
作者 | Mike Bursell
譯者 | Weston JI (erlinux) ? ? 共計翻譯：4 篇 貢獻時間：541 天
你可能並不想把所有的遺留應用全部分解為微服務，或許你可以考慮從安全功能開始。
我為了給這篇文章起個標題，使出 “洪荒之力”，也很擔心這會變成標題黨。如果你點選它，是因為它激起了你的好奇，那麼我表示抱歉 註1[1] 。我當然是希望你留下來閱讀的 註2[2] ：我有很多有趣的觀點以及很多 註3[3] 腳註。我不是故意提出微服務會導致安全問題——儘管如同很多元件一樣都有安全問題。當然，這些微服務是那些安全方面的人員的趣向所在。進一步地說，我認為對於那些擔心安全的人來說，它們是優秀的架構。
為什麼這樣說？這是個好問題，對於我們這些有系統安全[4] 經驗的人來說，此時這個世界才是一個有趣的地方。我們看到隨著頻寬便宜了並且延遲降低了，分散式系統在增長。加上部署到雲愈加便利，越來越多的架構師們開始意識到應用是可以分解的，不只是分成多個層，並且層內還能分為多個元件。當然，均衡負載可以用於讓一個層內的各個元件協同工作，但是將不同的服務輸出為各種小元件的能力導致了微服務在設計、實施和部署方面的增長。
所以，到底什麼是微服務呢[5]？我同意維基百科的定義[6]，儘管沒有提及安全性方面的內容註4[7] 。 我喜歡微服務的一點是，經過精心設計，其符合 Peter H. Salus 描述的 UNIX 哲學[8] 的前倆點：
三者中最後一個有點不太相關，因為 UNIX 哲學通常被用來指代獨立應用，它常有一個實體化的命令。但是，它確實包含了微服務的基本要求之一：必須具有“定義明確”的介面。
這裡的“定義明確”，我指的不僅僅是可外部訪問的 API 的方法描述，也指正常的微服務輸入輸出操作——以及，如果有的話，還有其副作用。就像我之前的文章描述的，“良好的系統架構的五個特徵[9]”，如果你能夠去設計一個系統，資料和主體描述是至關重要的。在此，在我們的微服務描述上，我們要去看看為什麼這些是如此重要。因為對我來說，微服務架構的關鍵定義是可分解性。如果你要分解 註5[10] 你的架構，你必須非常、非常地清楚每個細節（“元件”）要做什麼。
在這裡，就要開始考慮安全了。特定元件的準確描述可以讓你：
現在，這些微服務能用在一個大型架構裡了嗎？是的。但如果物體是在更複雜的配置中彼此連結或組合在一起，它們會隨之越來越難。當你讓一小部分可以彼此配合工作時，確保正確的實施和行為是非常、非常容易的。並且如果你不能確定單個元件正在做它們應該作的，那麼確保其衍生出來的複雜系統的正確行為及不正確行為就困難的多了。
而且還不止於此。如我已經在許多以往場合[11]提過的，寫足夠安全的程式碼是困難的註7[12] ，證實它應該做的更加困難。因此，有理由限制有特定安全要求的程式碼——密碼檢測、加密、加密金鑰管理、授權等等——將它們變成小而定義明確的程式碼塊。然後你就可以執行我上面提及所有工作，以確保正確完成。
還有，我們都知道並不是每個人都擅長於編寫與安全相關的程式碼。透過分解你的體系架構，將安全敏感的程式碼限制到定義明確的元件中，你就可以把你最棒的安全人員放到這方面，並限制了 J.佛系.碼奴 註8[13] 繞過或降級一些關鍵的安全控制措施的危險。
它可以作為學習的機會：它對於設計/實現/測試/監視的兄弟們都是好的，而且給他們說：“聽、讀、標記、學習，並且引為己用 註9[14] 。這是應該做的。”
是否應該將所有遺留應用程式分解為微服務？ 不一定。 但是考慮到其帶來的好處，你可以考慮從安全入手。
這篇文章最初出在愛麗絲、伊娃與鮑伯[16]——一個安全部落格上，並被許可轉載。
via: https://opensource.com/article/17/11/microservices-are-security-issue
作者：Mike Bursell[11] 譯者：erlinux[18] 校對：wxy
本文由 LCTT 原創編譯，Linux中國 榮譽推出
