建站
咨詢
售后
建站咨詢
新聞中心
到目前為止，大多數(shù)開發(fā)人員已聽說了微服務(wù)的種種好處。不過，真正通過將現(xiàn)有應(yīng)用程序轉(zhuǎn)換成微服務(wù)架構(gòu)以“遷移整體式系統(tǒng)”時，你可能會發(fā)現(xiàn)設(shè)計有效的微服務(wù)架構(gòu)困難重重。開發(fā)社區(qū)費(fèi)了大量的時間討論為何采用微服務(wù)架構(gòu)，而不是討論如何設(shè)計。
本文介紹了設(shè)計成功的微服務(wù)架構(gòu)的幾個優(yōu)秀實(shí)踐。我們不會介紹開發(fā)或部署微服務(wù)，而是討論計劃使用微服務(wù)架構(gòu)時應(yīng)避免的常見錯誤。
1. 癡迷于每項功能有一個服務(wù)
讓大多數(shù)開發(fā)人員描述有效的微服務(wù)架構(gòu)，他們會告訴你應(yīng)用程序每方面的功能都應(yīng)該由不同的微服務(wù)提供支持。以支付應(yīng)用程序?yàn)槔?，身份?yàn)證應(yīng)由一個微服務(wù)處理，另一個微服務(wù)進(jìn)行支付處理，另一個微服務(wù)運(yùn)行前端，另一個存儲和檢索數(shù)據(jù)，依此類推。
旨在將各大應(yīng)用功能派給不同的微服務(wù)通常是個好主意。但是這個原則很容易過猶不及，往往會阻礙設(shè)計有效的微服務(wù)架構(gòu)。
有時，區(qū)別一項功能與另一項功能的界線很模糊。比如說，你是否應(yīng)該將用戶注冊視作與用戶身份驗(yàn)證不同的功能，因此為各自創(chuàng)建單獨(dú)的微服務(wù)?如果你的應(yīng)用程序?qū)?shù)據(jù)存儲在多個位置，每個位置都應(yīng)該擁有自己的微服務(wù)嗎?還是應(yīng)該只有一個數(shù)據(jù)服務(wù)來處理所有位置?
這些問題的答案是，這可能無關(guān)緊要。要弄清楚某應(yīng)用程序?qū)⒂卸嗌傥⒎?wù)、各自處理哪些功能。如果你花太多的時間弄清楚如何在應(yīng)用程序中拆分不同的任務(wù)，工作效率就不會很高。
2. 微服務(wù)做得過小
同樣，設(shè)計微服務(wù)架構(gòu)使每個微服務(wù)過小，因此需要眾多微服務(wù)來組成整個應(yīng)用程序是常見的錯誤。
開發(fā)人員之所以遇到這個陷阱，是由于他們認(rèn)為微服務(wù)越小越好。從某種意義上說是對的——將大型應(yīng)用程序分成較小的離散單元是為應(yīng)用程序提高可擴(kuò)展性和可靠性的一種方法。
但是如果微服務(wù)變得過小，以后開發(fā)和部署微服務(wù)時開銷會大大增加。每個微服務(wù)需要各自的開發(fā)和部署管道(更不用說單獨(dú)的監(jiān)控、日志和安全操作了)。
因此，雖然你確實(shí)希望微服務(wù)小點(diǎn)，但不應(yīng)該過小，也不應(yīng)該讓應(yīng)用程序含有太多的微服務(wù)。作為一條普遍的準(zhǔn)則，如果你的應(yīng)用程序由不止十幾個微服務(wù)組成，每個微服務(wù)可能太小，你應(yīng)該將一些微服務(wù)合并起來，以不同的方式來設(shè)計架構(gòu)。
3. 需要特定的部署解決方案
如今的常見做法是通過容器來部署微服務(wù)——通常借助OpenShift或另一種基于Kubernetes的編排平臺。
但幾年后還會是這樣嗎?不好說。部署技術(shù)日新月異，很難知道哪種部署解決方案將來對你的微服務(wù)應(yīng)用最合理。
因此，以需要特定類型部署技術(shù)的方式設(shè)計微服務(wù)架構(gòu)是錯誤的。你不應(yīng)該讓自己依賴Kubernetes、甚至普通的容器才能部署應(yīng)用程序，而是應(yīng)設(shè)計一種可以在各種基礎(chǔ)架構(gòu)上、甚至可以在各種操作系統(tǒng)上運(yùn)行的架構(gòu)。
4. 要求同時更新所有微服務(wù)
你有時在微服務(wù)架構(gòu)中看到的一個錯誤是要求：如果更新應(yīng)用程序中的一個微服務(wù)，同時也要更新(或至少重新啟動)其他微服務(wù)。
如果從整體式系統(tǒng)的角度來看，這種想法很自然。但是就微服務(wù)而言，這種方法意味著你是自找麻煩。微服務(wù)的目的一方面是在不影響其他部分的情況下，更新、擴(kuò)展或重新啟動應(yīng)用程序的某些部分。
因此，如果更改一個微服務(wù)的狀態(tài)意味著也要更改其他微服務(wù)的狀態(tài)，你就失去了微服務(wù)本該帶來的許多靈活性。也更難搞持續(xù)交付，因?yàn)槟銦o法在不影響其他服務(wù)的情況下推送針對某一服務(wù)的更新。
另一方面，你的微服務(wù)不應(yīng)太緊密地耦合在一起。設(shè)計架構(gòu)時盡可能避免這種情況：如果依賴的另一個微服務(wù)沒在運(yùn)行，某一微服務(wù)就無法運(yùn)行。
5. 忽視日志
設(shè)計微服務(wù)架構(gòu)時要避免的最后一個陷阱是忽視日志。
很容易犯這個錯誤。你會以為可以在以后為每個微服務(wù)編寫代碼時搞清楚日志，或者只要將日志代理部署到微服務(wù)環(huán)境中，它就能收集所需的所有數(shù)據(jù)。
最好一開始就將日志納入到微服務(wù)架構(gòu)中。在許多情況下，這意味著專門創(chuàng)建一個微服務(wù)，用于從其他微服務(wù)收集日志數(shù)據(jù)。不過在其他情況下，每個微服務(wù)可能會進(jìn)行自己的日志記錄，將數(shù)據(jù)重定向到中心位置。
無論采用哪種策略，目的都應(yīng)該是確保微服務(wù)架構(gòu)便于從整個應(yīng)用程序收集日志數(shù)據(jù)，并將其放入到中心位置以便分析和保存。
結(jié)論
設(shè)計微服務(wù)時沒有一成不變的規(guī)定。不過作為一般準(zhǔn)則，上述原則仍將幫助你規(guī)劃好這樣的微服務(wù)架構(gòu)：提供微服務(wù)本應(yīng)提供的所有好處，又沒有因?yàn)樵愀庠O(shè)計的微服務(wù)架構(gòu)給開發(fā)人員和IT團(tuán)隊帶來的麻煩。
分享文章：設(shè)計微服務(wù)架構(gòu)時應(yīng)避免的五個錯誤
本文鏈接：http://www.dlmjj.cn/article/dhpepoh.html
