[[316471]]

【51CTO.com快譯】到目前為止，大多數開發人員已聽說了微服務的種種好處。不過，真正通過將現有應用程序轉換成微服務架構以“遷移整體式系統”時，你可能會發現設計有效的微服務架構困難重重。開發社區費了大量的時間討論為何采用微服務架構，而不是討論如何設計。

本文介紹了設計成功的微服務架構的幾個優秀實踐。我們不會介紹開發或部署微服務，而是討論計劃使用微服務架構時應避免的常見錯誤。

1. 癡迷于每項功能有一個服務

讓大多數開發人員描述有效的微服務架構，他們會告訴你應用程序每方面的功能都應該由不同的微服務提供支持。以支付應用程序為例，身份驗證應由一個微服務處理，另一個微服務進行支付處理，另一個微服務運行前端，另一個存儲和檢索數據，依此類推。

旨在將各大應用功能派給不同的微服務通常是個好主意。但是這個原則很容易過猶不及，往往會阻礙設計有效的微服務架構。

有時，區別一項功能與另一項功能的界線很模糊。比如說，你是否應該將用戶注冊視作與用戶身份驗證不同的功能，因此為各自創建單獨的微服務?如果你的應用程序將數據存儲在多個位置，每個位置都應該擁有自己的微服務嗎?還是應該只有一個數據服務來處理所有位置?

這些問題的答案是，這可能無關緊要。要弄清楚某應用程序將有多少微服務、各自處理哪些功能。如果你花太多的時間弄清楚如何在應用程序中拆分不同的任務，工作效率就不會很高。

2. 微服務做得過小

同樣，設計微服務架構使每個微服務過小，因此需要眾多微服務來組成整個應用程序是常見的錯誤。

開發人員之所以遇到這個陷阱，是由于他們認為微服務越小越好。從某種意義上說是對的——將大型應用程序分成較小的離散單元是為應用程序提高可擴展性和可靠性的一種方法。

但是如果微服務變得過小，以后開發和部署微服務時開銷會大大增加。每個微服務需要各自的開發和部署管道(更不用說單獨的監控、日志和安全操作了)。

因此，雖然你確實希望微服務小點，但不應該過小，也不應該讓應用程序含有太多的微服務。作為一條普遍的準則，如果你的應用程序由不止十幾個微服務組成，每個微服務可能太小，你應該將一些微服務合并起來，以不同的方式來設計架構。

3. 需要特定的部署解決方案

如今的常見做法是通過容器來部署微服務——通常借助OpenShift或另一種基于Kubernetes的編排平臺。

但幾年后還會是這樣嗎?不好說。部署技術日新月異，很難知道哪種部署解決方案將來對你的微服務應用最合理。

因此，以需要特定類型部署技術的方式設計微服務架構是錯誤的。你不應該讓自己依賴Kubernetes、甚至普通的容器才能部署應用程序，而是應設計一種可以在各種基礎架構上、甚至可以在各種操作系統上運行的架構。

4. 要求同時更新所有微服務

你有時在微服務架構中看到的一個錯誤是要求：如果更新應用程序中的一個微服務，同時也要更新(或至少重新啟動)其他微服務。

如果從整體式系統的角度來看，這種想法很自然。但是就微服務而言，這種方法意味著你是自找麻煩。微服務的目的一方面是在不影響其他部分的情況下，更新、擴展或重新啟動應用程序的某些部分。

因此，如果更改一個微服務的狀態意味著也要更改其他微服務的狀態，你就失去了微服務本該帶來的許多靈活性。也更難搞持續交付，因為你無法在不影響其他服務的情況下推送針對某一服務的更新。

另一方面，你的微服務不應太緊密地耦合在一起。設計架構時盡可能避免這種情況：如果依賴的另一個微服務沒在運行，某一微服務就無法運行。

5. 忽視日志

設計微服務架構時要避免的最后一個陷阱是忽視日志。

很容易犯這個錯誤。你會以為可以在以后為每個微服務編寫代碼時搞清楚日志，或者只要將日志代理部署到微服務環境中，它就能收集所需的所有數據。

最好一開始就將日志納入到微服務架構中。在許多情況下，這意味著專門創建一個微服務，用于從其他微服務收集日志數據。不過在其他情況下，每個微服務可能會進行自己的日志記錄，將數據重定向到中心位置。

無論采用哪種策略，目的都應該是確保微服務架構便于從整個應用程序收集日志數據，并將其放入到中心位置以便分析和保存。

結論

設計微服務時沒有一成不變的規定。不過作為一般準則，上述原則仍將幫助你規劃好這樣的微服務架構：提供微服務本應提供的所有好處，又沒有因為糟糕設計的微服務架構給開發人員和IT團隊帶來的麻煩。

原文標題：5 Mistakes to Avoid When Designing a Microservices Architecture，作者：Christopher Tozzi

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】