[[316471]]

【51CTO.com快譯】到目前為止，大多數(shù)開發(fā)人員已聽說了微服務(wù)的種種好處。不過，真正通過將現(xiàn)有應(yīng)用程序轉(zhuǎn)換成微服務(wù)架構(gòu)以“遷移整體式系統(tǒng)”時(shí)，你可能會(huì)發(fā)現(xiàn)設(shè)計(jì)有效的微服務(wù)架構(gòu)困難重重。開發(fā)社區(qū)費(fèi)了大量的時(shí)間討論為何采用微服務(wù)架構(gòu)，而不是討論如何設(shè)計(jì)。

本文介紹了設(shè)計(jì)成功的微服務(wù)架構(gòu)的幾個(gè)優(yōu)秀實(shí)踐。我們不會(huì)介紹開發(fā)或部署微服務(wù)，而是討論計(jì)劃使用微服務(wù)架構(gòu)時(shí)應(yīng)避免的常見錯(cuò)誤。

1. 癡迷于每項(xiàng)功能有一個(gè)服務(wù)

讓大多數(shù)開發(fā)人員描述有效的微服務(wù)架構(gòu)，他們會(huì)告訴你應(yīng)用程序每方面的功能都應(yīng)該由不同的微服務(wù)提供支持。以支付應(yīng)用程序?yàn)槔?，身份?yàn)證應(yīng)由一個(gè)微服務(wù)處理，另一個(gè)微服務(wù)進(jìn)行支付處理，另一個(gè)微服務(wù)運(yùn)行前端，另一個(gè)存儲(chǔ)和檢索數(shù)據(jù)，依此類推。

旨在將各大應(yīng)用功能派給不同的微服務(wù)通常是個(gè)好主意。但是這個(gè)原則很容易過猶不及，往往會(huì)阻礙設(shè)計(jì)有效的微服務(wù)架構(gòu)。

有時(shí)，區(qū)別一項(xiàng)功能與另一項(xiàng)功能的界線很模糊。比如說，你是否應(yīng)該將用戶注冊視作與用戶身份驗(yàn)證不同的功能，因此為各自創(chuàng)建單獨(dú)的微服務(wù)?如果你的應(yīng)用程序?qū)?shù)據(jù)存儲(chǔ)在多個(gè)位置，每個(gè)位置都應(yīng)該擁有自己的微服務(wù)嗎?還是應(yīng)該只有一個(gè)數(shù)據(jù)服務(wù)來處理所有位置?

這些問題的答案是，這可能無關(guān)緊要。要弄清楚某應(yīng)用程序?qū)⒂卸嗌傥⒎?wù)、各自處理哪些功能。如果你花太多的時(shí)間弄清楚如何在應(yīng)用程序中拆分不同的任務(wù)，工作效率就不會(huì)很高。

2. 微服務(wù)做得過小

同樣，設(shè)計(jì)微服務(wù)架構(gòu)使每個(gè)微服務(wù)過小，因此需要眾多微服務(wù)來組成整個(gè)應(yīng)用程序是常見的錯(cuò)誤。

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

但是如果微服務(wù)變得過小，以后開發(fā)和部署微服務(wù)時(shí)開銷會(huì)大大增加。每個(gè)微服務(wù)需要各自的開發(fā)和部署管道(更不用說單獨(dú)的監(jiān)控、日志和安全操作了)。

因此，雖然你確實(shí)希望微服務(wù)小點(diǎn)，但不應(yīng)該過小，也不應(yīng)該讓應(yīng)用程序含有太多的微服務(wù)。作為一條普遍的準(zhǔn)則，如果你的應(yīng)用程序由不止十幾個(gè)微服務(wù)組成，每個(gè)微服務(wù)可能太小，你應(yīng)該將一些微服務(wù)合并起來，以不同的方式來設(shè)計(jì)架構(gòu)。

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

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

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

因此，以需要特定類型部署技術(shù)的方式設(shè)計(jì)微服務(wù)架構(gòu)是錯(cuò)誤的。你不應(yīng)該讓自己依賴Kubernetes、甚至普通的容器才能部署應(yīng)用程序，而是應(yīng)設(shè)計(jì)一種可以在各種基礎(chǔ)架構(gòu)上、甚至可以在各種操作系統(tǒng)上運(yùn)行的架構(gòu)。

4. 要求同時(shí)更新所有微服務(wù)

你有時(shí)在微服務(wù)架構(gòu)中看到的一個(gè)錯(cuò)誤是要求：如果更新應(yīng)用程序中的一個(gè)微服務(wù)，同時(shí)也要更新(或至少重新啟動(dòng))其他微服務(wù)。

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

因此，如果更改一個(gè)微服務(wù)的狀態(tài)意味著也要更改其他微服務(wù)的狀態(tài)，你就失去了微服務(wù)本該帶來的許多靈活性。也更難搞持續(xù)交付，因?yàn)槟銦o法在不影響其他服務(wù)的情況下推送針對某一服務(wù)的更新。

另一方面，你的微服務(wù)不應(yīng)太緊密地耦合在一起。設(shè)計(jì)架構(gòu)時(shí)盡可能避免這種情況：如果依賴的另一個(gè)微服務(wù)沒在運(yùn)行，某一微服務(wù)就無法運(yùn)行。

5. 忽視日志

設(shè)計(jì)微服務(wù)架構(gòu)時(shí)要避免的最后一個(gè)陷阱是忽視日志。

很容易犯這個(gè)錯(cuò)誤。你會(huì)以為可以在以后為每個(gè)微服務(wù)編寫代碼時(shí)搞清楚日志，或者只要將日志代理部署到微服務(wù)環(huán)境中，它就能收集所需的所有數(shù)據(jù)。

最好一開始就將日志納入到微服務(wù)架構(gòu)中。在許多情況下，這意味著專門創(chuàng)建一個(gè)微服務(wù)，用于從其他微服務(wù)收集日志數(shù)據(jù)。不過在其他情況下，每個(gè)微服務(wù)可能會(huì)進(jìn)行自己的日志記錄，將數(shù)據(jù)重定向到中心位置。

無論采用哪種策略，目的都應(yīng)該是確保微服務(wù)架構(gòu)便于從整個(gè)應(yīng)用程序收集日志數(shù)據(jù)，并將其放入到中心位置以便分析和保存。

結(jié)論

設(shè)計(jì)微服務(wù)時(shí)沒有一成不變的規(guī)定。不過作為一般準(zhǔn)則，上述原則仍將幫助你規(guī)劃好這樣的微服務(wù)架構(gòu)：提供微服務(wù)本應(yīng)提供的所有好處，又沒有因?yàn)樵愀庠O(shè)計(jì)的微服務(wù)架構(gòu)給開發(fā)人員和IT團(tuán)隊(duì)帶來的麻煩。

原文標(biāo)題：5 Mistakes to Avoid When Designing a Microservices Architecture，作者：Christopher Tozzi

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