建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
在這篇文章里，我將簡(jiǎn)要地介紹在設(shè)計(jì)微服務(wù)架構(gòu)時(shí)需要注意的問(wèn)題。如果實(shí)施得當(dāng)，就會(huì)獲得自治能力和靈活性，但同時(shí)也會(huì)帶來(lái)通信延遲和部署及托管成本。這篇文章并不是一個(gè)高級(jí)指南，我只是希望能夠在你們決定采用微服務(wù)架構(gòu)時(shí)幫你們做出更好的判斷。
成都創(chuàng)新互聯(lián)公司致力于成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作,成都網(wǎng)站設(shè)計(jì),集團(tuán)網(wǎng)站建設(shè)等服務(wù)標(biāo)準(zhǔn)化，推過(guò)標(biāo)準(zhǔn)化降低中小企業(yè)的建站的成本，并持續(xù)提升建站的定制化服務(wù)水平進(jìn)行質(zhì)量交付，讓企業(yè)網(wǎng)站從市場(chǎng)競(jìng)爭(zhēng)中脫穎而出。 選擇成都創(chuàng)新互聯(lián)公司，就選擇了安全、穩(wěn)定、美觀(guān)的網(wǎng)站建設(shè)服務(wù)！
1. 映射服務(wù)
在我看來(lái)，映射服務(wù)是一種很糟糕的想法。
如果你走到了這一步，很可能是因?yàn)槟阈枰诜?wù) A 和服務(wù) B 之間映射 DTO，因?yàn)榉?wù) A 和服務(wù) B 需要不同的 DTO，但它們之間又相互依賴(lài)。出于對(duì)微服務(wù)的“熱愛(ài)”，你嘗試著解耦這兩個(gè)服務(wù)，于是你創(chuàng)建了服務(wù) C。服務(wù) C 接收 JSON 數(shù)據(jù)，并把稍微處理后的數(shù)據(jù)返回，其他什么事也不做。
現(xiàn)在，你的三個(gè)服務(wù)都耦合在一起了。DTO 到 DTO 的映射應(yīng)該發(fā)生在進(jìn)程內(nèi)部，否則的話(huà)，可能會(huì)有人創(chuàng)建出新的服務(wù)來(lái)映射服務(wù) A 和服務(wù) C 之間的 DTO。除非服務(wù) C 不會(huì)往實(shí)體中添加新數(shù)據(jù)，否則它的存在就不是必要的。一個(gè)服務(wù)應(yīng)該只返回它所擁有的數(shù)據(jù)。
同樣，你會(huì)為了給一組數(shù)字排序而專(zhuān)門(mén)創(chuàng)建一個(gè)服務(wù)嗎？
2. 靜態(tài)內(nèi)容的映射服務(wù)
并不是所有東西都需要被包裝成微服務(wù)，網(wǎng)站的靜態(tài)資源，比如腳本、樣式表或圖像，要么把它們放在主服務(wù)器上，要么放在 CDN 上。
對(duì)于后端服務(wù)，如果需要在初始化的時(shí)候讀取一些簡(jiǎn)單的字符串，而這些字符串很少發(fā)生變化，可能幾個(gè)月或者幾天才會(huì)修改一次，那么可以考慮使用冷存儲(chǔ)，比如亞馬遜的 S3 或者微軟的 BlogStorage。需要訪(fǎng)問(wèn)控制？可以考慮基于 IP 或域名的訪(fǎng)問(wèn)限制。所以，在考慮是否需要?jiǎng)?chuàng)建新的微服務(wù)時(shí)，要十分謹(jǐn)慎，因?yàn)樗赡軙?huì)給你帶來(lái)巨大的維護(hù)和托管成本。
另外請(qǐng)注意，持久存儲(chǔ)必須是分布式可伸縮的。出于簡(jiǎn)單起見(jiàn)，數(shù)據(jù)應(yīng)該采用鍵值對(duì)的形式，否則就會(huì)遇到與“多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)”一樣的問(wèn)題。
3. 將應(yīng)用程序的配置托管在遠(yuǎn)程服務(wù)上
線(xiàn)程池該配置多少個(gè)線(xiàn)程？重試策略該怎么配？本地內(nèi)存緩存的有效時(shí)間設(shè)置多久合適？需要通過(guò)一個(gè)遠(yuǎn)程服務(wù)來(lái)配置這些東西嗎？在很多情況下，把這些東西放在配置文件或者環(huán)境變量里是完全可以的，所以可以先考慮這種方式。如果不行，可以嘗試一些已有的配置工具，比如 Consul，盡量避免自己開(kāi)發(fā)浪費(fèi)時(shí)間和精力。
4. 多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)
如果架構(gòu)過(guò)于簡(jiǎn)單，很快也會(huì)遇到問(wèn)題。如果多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的連接、存儲(chǔ)空間和計(jì)算能力很快就會(huì)不夠用。接下來(lái)就會(huì)出現(xiàn)一些不太好的局面——一些服務(wù)使用的表被刪掉了?；蛘撸袃蓚€(gè)客戶(hù)端使用了同一張表，其中一個(gè)客戶(hù)單要求對(duì)表結(jié)構(gòu)做出修改，這個(gè)時(shí)候就需要做一些適配才能不影響另一個(gè)客戶(hù)端。在我看來(lái)，現(xiàn)在的系統(tǒng)變成了一個(gè)分布式單體。
這樣做有悖微服務(wù)架構(gòu)的原則，因?yàn)槲⒎?wù)應(yīng)該是獨(dú)立且自包含的。它們應(yīng)該擁有自己的數(shù)據(jù)，并可以完全自由決定該怎么持久化數(shù)據(jù)。它們存在的目的是為了解耦，為了獲得這種靈活性，需要付出一定的代價(jià)，但追求靈活性應(yīng)該成為你的目標(biāo)。
微服務(wù)之間應(yīng)該通過(guò)公開(kāi)暴露的 API 進(jìn)行交互。基于 HTTP 的通信可以選擇 REST、GraphQL、gRPC，或者也可以使用消息隊(duì)列，比如 RabbitMQ、Apache Kafka。
5. 結(jié)論
希望你們大部分人都很清楚上述的這些問(wèn)題，不過(guò)肯定會(huì)有一些人犯下這些錯(cuò)誤，也許看了本文后你能學(xué)到一些。不管怎樣，在微服務(wù)這個(gè)新奇和多變的世界里犯點(diǎn)錯(cuò)誤是在所難免的。
網(wǎng)站欄目：微服務(wù)架構(gòu)陷阱：過(guò)渡設(shè)計(jì)和設(shè)計(jì)不足
文章源于：http://www.fisionsoft.com.cn/article/djjoodc.html
