編譯自： https://opensource.com/article/17/11/microservices-are-security-issue譯者： Weston JI
你可能並不想把所有的遺留應用全部分解為微服務，或許你可以考慮從安全功能開始。
我為了給這篇文章起個標題，使出 “洪荒之力”，也很擔心這會變成標題黨。如果你點擊它，是因為它激起了你的好奇，那麼我表示抱歉 注1[1] 。我當然是希望你留下來閱讀的 注2[2] ：我有很多有趣的觀點以及很多 注3[3] 腳註。我不是故意提出微服務會導致安全問題——儘管如同很多組件一樣都有安全問題。當然，這些微服務是那些安全方面的人員的趣向所在。進一步地說，我認為對於那些擔心安全的人來說，它們是優秀的架構。
為什麼這樣說？這是個好問題，對於我們這些有系統安全[4] 經驗的人來說，此時這個世界才是一個有趣的地方。我們看到隨著帶寬便宜了並且延遲降低了，分佈式系統在增長。加上部署到雲愈加便利，越來越多的架構師們開始意識到應用是可以分解的，不只是分成多個層，並且層內還能分為多個組件。當然，均衡負載可以用於讓一個層內的各個組件協同工作，但是將不同的服務輸出為各種小組件的能力導致了微服務在設計、實施和部署方面的增長。
所以，到底什麼是微服務呢[5]？我同意維基百科的定義[6]，儘管沒有提及安全性方面的內容注4[7] 。 我喜歡微服務的一點是，經過精心設計，其符合 Peter H. Salus 描述的 UNIX 哲學[8] 的前倆點：
程序應該只做一件事，並儘可能把它做好。
讓程序能夠互相協同工作。
應該讓程序處理文本數據流，因為這是一個通用的接口。
三者中最後一個有點不太相關，因為 UNIX 哲學通常被用來指代獨立應用，它常有一個實例化的命令。但是，它確實包含了微服務的基本要求之一：必須具有“定義明確”的接口。
這裡的“定義明確”，我指的不僅僅是可外部訪問的 API 的方法描述，也指正常的微服務輸入輸出操作——以及，如果有的話，還有其副作用。就像我之前的文章描述的，“良好的系統架構的五個特徵[9]”，如果你能夠去設計一個系統，數據和主體描述是至關重要的。在此，在我們的微服務描述上，我們要去看看為什麼這些是如此重要。因為對我來說，微服務架構的關鍵定義是可分解性。如果你要分解 注5[10] 你的架構，你必須非常、非常地清楚每個細節（“組件”）要做什麼。
在這裡，就要開始考慮安全了。特定組件的準確描述可以讓你：
審查您的設計
確保您的實現符合描述
提出可重用測試單元來審查功能
跟蹤實施中的錯誤並糾正錯誤
測試意料之外的產出
監視不當行為
審核未來可能的實際行為
現在，這些微服務能用在一個大型架構裡了嗎？是的。但如果實體是在更復雜的配置中彼此鏈接或組合在一起，它們會隨之越來越難。當你讓一小部分可以彼此配合工作時，確保正確的實施和行為是非常、非常容易的。並且如果你不能確定單個組件正在做它們應該作的，那麼確保其衍生出來的複雜系統的正確行為及不正確行為就困難的多了。
還有，我們都知道並不是每個人都擅長於編寫與安全相關的代碼。通過分解你的體系架構，將安全敏感的代碼限制到定義明確的組件中，你就可以把你最棒的安全人員放到這方面，並限制了 J.佛系.碼奴 注8[13] 繞過或降級一些關鍵的安全控制措施的危險。
它可以作為學習的機會：它對於設計/實現/測試/監視的兄弟們都是好的，而且給他們說：“聽、讀、標記、學習，並且引為己用 注9[14] 。這是應該做的。”
是否應該將所有遺留應用程序分解為微服務？ 不一定。 但是考慮到其帶來的好處，你可以考慮從安全入手。
注1、有一點——有讀者總是好的。
注2、這是我寫下文章的意義。
注3、可能沒那麼有趣。
注5、這很有趣，聽起來想一個園藝術語。並不是說我很喜歡園藝，但仍然... 注6[15]
注6、有意思的是，我最先寫的 “如果你要分解你的架構....” 聽起來想是一個 IT 主題的謀殺電影標題。
注7、長期讀者可能會記得提到的優秀電影 “The Thick of It”
注8、其他的什麼人：請隨便選擇。
注9、不是加密 摘要(digest)：我不認同原作者的想法。
via: https://opensource.com/article/17/11/microservices-are-security-issue
閱讀更多 Linux技術 的文章
