建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
微服務(wù)“很香”，它有許多優(yōu)勢(shì)，比如更快的開(kāi)發(fā)、更好的可擴(kuò)展性、更小的獨(dú)立團(tuán)隊(duì)等等。但是，很多團(tuán)隊(duì)卻在微服務(wù)上舉步維艱，沒(méi)有很好利用其優(yōu)勢(shì)。原因到底是什么？這是本文作者試圖回答的。
過(guò)去幾年，我對(duì)推進(jìn)數(shù)字化轉(zhuǎn)型的多家產(chǎn)品團(tuán)隊(duì)進(jìn)行了架構(gòu)審查。我發(fā)現(xiàn)：大多數(shù)團(tuán)隊(duì)都是遵循微服務(wù)架構(gòu)來(lái)構(gòu)建產(chǎn)品。更快的開(kāi)發(fā)、更好的可擴(kuò)展性、更小的獨(dú)立團(tuán)隊(duì)、獨(dú)立部署和使用正確的技術(shù)來(lái)完成工作等等，這些優(yōu)勢(shì)讓他們有充足的理由采用微服務(wù)架構(gòu)。
但是，我經(jīng)常發(fā)現(xiàn)：很多團(tuán)隊(duì)在微服務(wù)上舉步維艱。他們并未充分利用微服務(wù)的優(yōu)勢(shì)。為什么許多團(tuán)隊(duì)在微服務(wù)之路上“舉步維艱”？這是我試圖回答的。
如果你是微服務(wù)新手，我推薦你閱讀 Martin Fowler 關(guān)于微服務(wù)的文章。
https://martinfowler.com/articles/microservices.html
這篇文章闡釋了何為微服務(wù)架構(gòu)：
微服務(wù)架構(gòu)的風(fēng)格是一種將單個(gè)應(yīng)用程序開(kāi)發(fā)成一套小型服務(wù)的方法，每個(gè)應(yīng)用程序都在自己的進(jìn)程中運(yùn)行，并與輕量級(jí)機(jī)制（通常是 HTTP 資源 API）進(jìn)行通信。這些服務(wù)是圍繞業(yè)務(wù)功能而構(gòu)建的，并且可以由完全自動(dòng)化的部署機(jī)制來(lái)獨(dú)立部署。這些服務(wù)只有最低限度的集中管理，可以用不同的編程語(yǔ)言編寫(xiě)，并使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。
1. 管理層低估開(kāi)發(fā)微服務(wù)的復(fù)雜性
我曾與許多非?？春梦⒎?wù)的客戶(hù)一起合作過(guò)。對(duì)他們來(lái)說(shuō)，微服務(wù)就是解決他們所有問(wèn)題的“靈丹妙藥”。
當(dāng)討論逐漸深入，我發(fā)現(xiàn)：大多數(shù)團(tuán)隊(duì)及其管理層都低估了微服務(wù)開(kāi)發(fā)的復(fù)雜性。
要開(kāi)發(fā)微服務(wù)，開(kāi)發(fā)人員需要一個(gè)高效的本地環(huán)境設(shè)置。
隨著系統(tǒng)中服務(wù)數(shù)量開(kāi)始增加，在一臺(tái)機(jī)器上運(yùn)行應(yīng)用程序的子集變得越來(lái)越困難。特別是當(dāng)你使用消耗較多內(nèi)存的語(yǔ)言（如 Java）構(gòu)建應(yīng)用程序時(shí)，更是如此。
下面是與本地開(kāi)發(fā)設(shè)置相關(guān)的要點(diǎn)：
- 本地開(kāi)發(fā)的第一個(gè)重要方面是要有一個(gè)好的開(kāi)發(fā)機(jī)器。
我發(fā)現(xiàn)，大多數(shù)組織想要使用所有最新的、最技術(shù)，但卻不想替換掉糟糕的 Windows 開(kāi)發(fā)機(jī)器。開(kāi)發(fā)人員受限于他們的開(kāi)發(fā)機(jī)器。我曾見(jiàn)過(guò)開(kāi)發(fā)人員使用 VDI 映像或配置交叉的機(jī)器來(lái)構(gòu)建基于微服務(wù)的系統(tǒng)。這不僅降低了他們的工作效率，而且讓他們無(wú)法完全投入工作。使用糟糕的開(kāi)發(fā)機(jī)器帶來(lái)的副作用就是，開(kāi)發(fā)人員無(wú)法得到快速反饋。如果知道了必須等數(shù)分鐘才能運(yùn)行集成測(cè)試套件，那么你就不會(huì)編寫(xiě)更多的集成測(cè)試套件，免得讓你更痛苦。糟糕的開(kāi)發(fā)機(jī)器將會(huì)導(dǎo)致糟糕的開(kāi)發(fā)實(shí)踐。
- 一旦你為開(kāi)發(fā)人員配備了合適的開(kāi)發(fā)機(jī)器，那么下一步就是確保所有服務(wù)都使用構(gòu)建工具。
你應(yīng)該能在一臺(tái)新機(jī)器上構(gòu)建整個(gè)應(yīng)用程序，而不需要進(jìn)行太多配置。根據(jù)我在微服務(wù)方面的經(jīng)驗(yàn)，使用能構(gòu)建整個(gè)應(yīng)用程序的根構(gòu)建腳本也會(huì)有所幫助。
- 下一個(gè)要點(diǎn)是要讓開(kāi)發(fā)人員能輕松地在他們的系統(tǒng)上運(yùn)行應(yīng)用程序的各個(gè)部分。在配置了所有端口和卷的情況下，你應(yīng)該使用多個(gè) docker-compose 文件來(lái)提供不同服務(wù)。
- 接下來(lái)，如果你使用的是類(lèi)似于 Kubernetes 的容器編排工具，那么你應(yīng)該投資類(lèi)似于 Telepresence 這樣的工具，以便輕松調(diào)試 Kubernetes 集群中的應(yīng)用程序。
如果組織對(duì)微服務(wù)開(kāi)發(fā)的復(fù)雜性缺乏理解，那么團(tuán)隊(duì)速度將會(huì)隨著時(shí)間的推移而下降。
2. 沒(méi)有將庫(kù)和工具更新到最新版
我發(fā)現(xiàn)一個(gè)新的平臺(tái)已經(jīng)成為一種遺產(chǎn)。團(tuán)隊(duì)沒(méi)有確保依賴(lài)項(xiàng)是最新的版本，或者將像數(shù)據(jù)庫(kù)這樣的工具升級(jí)到最新版本。
因此，兩年前開(kāi)始的現(xiàn)代化改造，如今已經(jīng)背負(fù)長(zhǎng)達(dá)數(shù)月的技術(shù)債。
幾年前，許多團(tuán)隊(duì)開(kāi)始將 Spring Cloud Netflix OSS 項(xiàng)目用于微服務(wù)。他們使用像 Kubernetes 這樣的容器編排工具，但是因?yàn)槭菑?Netflix OSS 開(kāi)始的，所以他們沒(méi)有使用 Kubernetes 提供的所有功能。當(dāng) Kubernetes 內(nèi)置了服務(wù)發(fā)現(xiàn)時(shí)，他們?nèi)匀皇褂?Eureka 作為服務(wù)發(fā)現(xiàn)。
此外，通過(guò)類(lèi)似 Istio 這樣的服務(wù)網(wǎng)格，你可以擺脫 Netflix OSS 提供的大部分服務(wù)。這有助于降低復(fù)雜性，并將許多“橫向關(guān)注點(diǎn)”（cross cutting concerns）轉(zhuǎn)移到平臺(tái)上。
需要記住的另一點(diǎn)是，要使所有服務(wù)的依賴(lài)項(xiàng)版本保持同步。
最近，我在幫助一個(gè)客戶(hù)，它使用 Spring Boot 來(lái)構(gòu)建微服務(wù)。在過(guò)去兩年，他們已經(jīng)構(gòu)建了 20 多個(gè) Spring Boot 服務(wù)。在其環(huán)境中，他們使用的 Spring Boot 版本從 1.5 到 2.1 不等。這意味著一旦有人設(shè)置他們的機(jī)器時(shí)，他們必須下載多個(gè)版本的 Spring Boot。
此外，他們還缺乏自 1.5 版本以來(lái)在 Spring Boot 中所做的許多改進(jìn)。
建議是，組織應(yīng)該在其積壓中為這些升級(jí)創(chuàng)建技術(shù)債務(wù)項(xiàng)。這些技術(shù)債務(wù)項(xiàng)應(yīng)作為架構(gòu)委員會(huì)會(huì)議的一部分加以討論，并定期予以解決。在我的上一個(gè)項(xiàng)目中，我們每三個(gè)月設(shè)置為期一周的 sprint，將所有依賴(lài)項(xiàng)更新到最新版本。
3. 利用共享服務(wù)促進(jìn)本地開(kāi)發(fā)
由于本地開(kāi)發(fā)狀況不佳，大多數(shù)團(tuán)隊(duì)開(kāi)始依賴(lài)于共享環(huán)境來(lái)獲得關(guān)鍵服務(wù)。開(kāi)發(fā)人員機(jī)器中的第一件事就是數(shù)據(jù)庫(kù)。大多數(shù)年輕的開(kāi)發(fā)人員并沒(méi)有意識(shí)到基于共享數(shù)據(jù)庫(kù)的開(kāi)發(fā)是“邪惡的”。
下面，是我在共享數(shù)據(jù)庫(kù)中看到的主要問(wèn)題：
- 團(tuán)隊(duì)成員必須建立一個(gè)工作的社會(huì)契約，以避免最后寫(xiě)入者勝出（Last write wins，LWW）問(wèn)題。一個(gè)開(kāi)發(fā)人員可以刪除其他開(kāi)發(fā)人員為他們工作編寫(xiě)的數(shù)據(jù)。這種工作方式既痛苦又容易失敗，遲早會(huì)影響整個(gè)團(tuán)隊(duì)。
- 開(kāi)發(fā)人員害怕實(shí)驗(yàn)，因?yàn)樗麄兊墓ぷ鲿?huì)影響其他團(tuán)隊(duì)成員。我們都知道，更好的學(xué)習(xí)方法是實(shí)驗(yàn)和快速反饋。有了共享數(shù)據(jù)庫(kù)，就可以進(jìn)行實(shí)驗(yàn)。我們需要進(jìn)行實(shí)驗(yàn)，以提出數(shù)據(jù)庫(kù)模式，并執(zhí)行任務(wù)，如性能調(diào)優(yōu)之類(lèi)。
- 另一個(gè)副作用就是，很難單獨(dú)測(cè)試更改。你的集成測(cè)試將變得不可靠，從而進(jìn)一步降低開(kāi)發(fā)速度。
- 共享數(shù)據(jù)庫(kù)必須像寵物一樣對(duì)待，因?yàn)槟悴幌Ｍ霈F(xiàn)不一致和不可預(yù)測(cè)的狀態(tài)。你可能會(huì)遇到這樣一種場(chǎng)景，開(kāi)發(fā)人員希望在表是空的時(shí)候測(cè)試邊緣情況，但其他開(kāi)發(fā)人員需要一個(gè)表來(lái)記錄。
- 只有共享數(shù)據(jù)庫(kù)擁有系統(tǒng)工作所需的所有數(shù)據(jù)。隨著時(shí)間推移，團(tuán)隊(duì)成員失去了更改的可追溯性，因此沒(méi)有人知道，他們?cè)撊绾卧谒麄兊臋C(jī)器上復(fù)制相同的設(shè)置。唯一的方法是獲取完整的數(shù)據(jù)庫(kù)轉(zhuǎn)儲(chǔ)并使用它。
- 如果未連接到網(wǎng)絡(luò)，就很難開(kāi)展工作。這種情況通常發(fā)生在你通勤時(shí)間過(guò)長(zhǎng)或乘飛機(jī)的時(shí)候。
數(shù)據(jù)庫(kù)只是共享服務(wù)的一個(gè)示例，但它也可以是消息隊(duì)列、集中緩存（如 Redis）或任何其他服務(wù)可以發(fā)生改變的服務(wù)。
解決這一問(wèn)題的最好方法是，讓開(kāi)發(fā)人員可以輕松地在他們的機(jī)器上運(yùn)行數(shù)據(jù)庫(kù)（作為 Docker 容器），并投資創(chuàng)建 SQL 腳本來(lái)設(shè)置模式和初始主數(shù)據(jù)。這些 SQL 腳本應(yīng)該保存在版本控制中，并像維護(hù)任何其他代碼一樣進(jìn)行維護(hù)。
4. 版本控制托管平臺(tái)缺乏可見(jiàn)性
我曾與一個(gè)客戶(hù)進(jìn)行合作，當(dāng)時(shí)，他們的版本控制系統(tǒng)中有 1000 多個(gè)倉(cāng)庫(kù)。他們使用的是 Gitlab 版本控制平臺(tái)。他們有 5 個(gè)產(chǎn)品，每個(gè)產(chǎn)品都由多個(gè)微服務(wù)組成。
我問(wèn)他們的第一個(gè)問(wèn)題是幫助我們了解哪些服務(wù)及其各自代碼庫(kù)是產(chǎn)品 A 的一部分。他們的首席架構(gòu)師不得不花一天時(shí)間弄清楚所有產(chǎn)品 A 的倉(cāng)庫(kù)。一天過(guò)去了，她還是不能確定是否弄清楚了所有服務(wù)。
解決這個(gè)問(wèn)題的最好方法是，從一開(kāi)始就以某種方式對(duì)你的微服務(wù)進(jìn)行分組，這樣，你就可以隨時(shí)了解產(chǎn)品的生態(tài)系統(tǒng)。Gitlab 提供一種方法來(lái)創(chuàng)建一個(gè)組，然后在其中創(chuàng)建項(xiàng)目倉(cāng)庫(kù)。Github 并沒(méi)有組功能，因此你可以使用主題或命名約定來(lái)實(shí)現(xiàn)它。
我個(gè)人更喜歡 mono repos，因?yàn)槲野l(fā)現(xiàn)他們真的很方便。我遇到的大多數(shù)開(kāi)發(fā)人員都認(rèn)為它是一種反模式。我同意 Dan Lua 的觀點(diǎn)，他提到了 mono repo 的以下好處：
- 簡(jiǎn)化的組織
- 簡(jiǎn)化的依賴(lài)關(guān)系
- 工具
- 跨項(xiàng)目變更
5. 服務(wù)沒(méi)有明確定義
大多數(shù)團(tuán)隊(duì)并不知道什么應(yīng)該被視為服務(wù)。關(guān)于究竟是什么構(gòu)成一個(gè)單一的微服務(wù)，人們對(duì)此存在很多混淆的認(rèn)識(shí)和困惑的概念。
讓我們舉一個(gè)例子，假設(shè)你的應(yīng)用程序具有類(lèi)似插件的架構(gòu)，在這個(gè)架構(gòu)中，你集成了多個(gè)第三方服務(wù)。每個(gè)集成應(yīng)該是一個(gè)微服務(wù)嗎？我看到很多團(tuán)隊(duì)，都在為每個(gè)集成創(chuàng)建一個(gè)微服務(wù)。隨著集成數(shù)量的增加，這種情況很快就會(huì)失控，以至于無(wú)法管理。這些服務(wù)通常太小，以至于將它們作為單獨(dú)的進(jìn)程運(yùn)行，會(huì)增加更多的開(kāi)銷(xiāo)。
我認(rèn)為，哪怕只擁有少量的大型服務(wù)，總比提供太多的小型服務(wù)要好得多。我將從創(chuàng)建一個(gè)服務(wù)開(kāi)始，該服務(wù)對(duì)業(yè)務(wù)組織中的整個(gè)部門(mén)進(jìn)行建模。這也符合 DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)， Domain Driven Design）。我將一個(gè)域分為子域和有界上下文。有界上下文表示公司內(nèi)部的一個(gè)部門(mén)，如財(cái)務(wù)部門(mén)和營(yíng)銷(xiāo)部門(mén)。你可能認(rèn)為，這會(huì)導(dǎo)致大型服務(wù)的出現(xiàn)，你是對(duì)的。
隨著知識(shí)經(jīng)驗(yàn)越來(lái)越多，你可以轉(zhuǎn)向代表更小問(wèn)題的細(xì)粒度微服務(wù)。你能應(yīng)用單一責(zé)任原則（Single Responsibility Principle）來(lái)了解微服務(wù)是否變得過(guò)大，做的事情是否過(guò)多。
然后，你可以將它分解成更小的獨(dú)立服務(wù)。任何服務(wù)都不應(yīng)該直接與其他服務(wù)的數(shù)據(jù)庫(kù)通信。他們應(yīng)該只通過(guò)已發(fā)布的合同進(jìn)行溝通。在 Microservices.io 網(wǎng)站上，你能了解更多關(guān)于按子域模式分解的內(nèi)容。
https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
我也遵循了 Backendlore 文檔中提到的建議。
https://github.com/fpereiro/backendlore
這個(gè)建議可以幫助將服務(wù)限制在服務(wù)通信上，而服務(wù)通信是微服務(wù)系統(tǒng)性能低下的首要原因。如果兩條信息相互依賴(lài)，那么它們應(yīng)該屬于同一個(gè)服務(wù)器。換句話(huà)說(shuō)，服務(wù)的自然邊界應(yīng)該是其數(shù)據(jù)的自然邊界。
6. 代碼重用策略不明確
我曾經(jīng)和一個(gè)客戶(hù)合作，該客戶(hù)在他們所有基于 Java 的微服務(wù)復(fù)制了四個(gè)與特定問(wèn)題相關(guān)的 Java 文件。因此，如果在該代碼中發(fā)現(xiàn) bug 的話(huà)，就需要將其修復(fù)應(yīng)用到所有地方。我們都知道，在時(shí)間緊迫的情況下，我們會(huì)錯(cuò)過(guò)將更改應(yīng)用于一個(gè)或多個(gè)服務(wù)。這樣會(huì)浪費(fèi)更多時(shí)間，增加挫敗感。
這并非說(shuō)開(kāi)發(fā)團(tuán)隊(duì)不懂正確的事情。但是，按照組織結(jié)構(gòu)，人們總是默認(rèn)采用簡(jiǎn)單且容易出錯(cuò)的做事方式。
正確的方法是，使用像 Bintray 或 Nexus 這樣的工件管理器，并在那里發(fā)布依賴(lài)項(xiàng)。然后，每個(gè)微服務(wù)都應(yīng)該依賴(lài)于這個(gè)庫(kù)。你需要構(gòu)建工具，以便在發(fā)布新版本的庫(kù)時(shí)，所有的微服務(wù)都應(yīng)該進(jìn)行更新和重新部署。
使用微服務(wù)并不意味著你不應(yīng)該使用迄今為止對(duì)我們有用的最佳實(shí)踐。你需要對(duì)工具進(jìn)行投資，使微服務(wù)的升級(jí)變得更容易，這樣人們就不必這樣做了。
在沒(méi)有適合的工具和自動(dòng)化的情況下，使用微服務(wù)會(huì)導(dǎo)致災(zāi)難。
7. 多語(yǔ)言編程設(shè)計(jì)
我發(fā)現(xiàn)團(tuán)隊(duì)使用多種編程語(yǔ)言、多種數(shù)據(jù)庫(kù)、多種緩存，并以最佳工具的名義進(jìn)行工作。所有這些都在項(xiàng)目初始階段起作用，但隨著你的產(chǎn)品投入生產(chǎn)，這些選擇開(kāi)始顯露“本色”。
原因就像我們?cè)跇?gòu)建 JavaSpringBoot 應(yīng)用程序，但是我們意識(shí)到 Java 占用更多的內(nèi)存，而且性能也很差，所以我們決定改用 Node.js。在我的上一次任務(wù)中，我向團(tuán)隊(duì)解釋說(shuō)他們的推理能力很弱。
（1）Note.js 比 Java 性能更好
如果你的工作負(fù)載是基于 I/O 的，Node.js 通常會(huì)表現(xiàn)的更好。但在任何計(jì)算密集型的工作負(fù)載上，Java 都勝過(guò) Node.js。通過(guò)響應(yīng)式范式（reactive paradigm），你可以使用 Java 為 I/O 工作負(fù)載提供更好性能。在 I/O 工作負(fù)載方面，Spring Boot Reactor 的性能相當(dāng)于 Node.js。
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html
https://blogs.sap.com/2018/08/03/spring-boot-reactive-vs.-node.js-in-sap-cloud-platform-reflection-on-throughput-measurement/
（2）Node.js 比 Java 消耗更少的內(nèi)存
在一定程度上，這是正確的說(shuō)法。Java Spring Boot 應(yīng)用程序并不像大多數(shù)想象的那么糟糕。我在一個(gè) Spring Boot Java 微服務(wù)上運(yùn)行了負(fù)載測(cè)試，內(nèi)存消耗仍然沒(méi)超過(guò) 1 GB。你可以通過(guò) OpenJ9 JVN，限制對(duì)類(lèi)路徑的依賴(lài)，并通過(guò)調(diào)優(yōu)默認(rèn)的 JVM 參數(shù)來(lái)優(yōu)化 Java 內(nèi)存利用率。此外，在 Java 中還有 Spring Boot 的新替代品，如 Micronaut 和 Quarkus，它們消耗的內(nèi)存相當(dāng)于 Node.js。
（3）Node.js 比 Java 效率更高
這取決于編寫(xiě)代碼的開(kāi)發(fā)人員。使用靜態(tài)類(lèi)型和靜態(tài)分析工具的 Java 可以幫助在開(kāi)發(fā)生命周期的早期發(fā)現(xiàn)問(wèn)題。
大多數(shù)情況下，這完全取決于上下文。如果你的開(kāi)發(fā)人員還不夠成熟的話(huà)，那么無(wú)論你使用什么編程語(yǔ)言，你開(kāi)發(fā)的都將是糟糕的產(chǎn)品。
我建議一家組織要發(fā)布一個(gè)團(tuán)隊(duì)可以使用的語(yǔ)言列表。我認(rèn)為 2~3 就是個(gè)很不錯(cuò)的數(shù)字。另外，要列出一種語(yǔ)言比另一種語(yǔ)言更適合的理由。
在選擇一門(mén)語(yǔ)言前，你應(yīng)該考慮以下一些問(wèn)題：
- 找到成熟的企業(yè)軟件開(kāi)發(fā)人員有多容易？
- 重新培訓(xùn)開(kāi)發(fā)人員掌握新技術(shù)有多容易？我們發(fā)現(xiàn) Java 開(kāi)發(fā)人員可以相對(duì)容易地學(xué)習(xí) Golang。
- 初始團(tuán)隊(duì)之外的開(kāi)發(fā)人員貢獻(xiàn)、轉(zhuǎn)移和維護(hù)其他人編寫(xiě)的代碼有多容易？
- 就工具和庫(kù)的方面而言，生態(tài)系統(tǒng)有多成熟？
這不僅僅局限于編程語(yǔ)言，也適用于數(shù)據(jù)庫(kù)領(lǐng)域。如果你的系統(tǒng)中已經(jīng)有了 MongoDB，那么你為什么要在生態(tài)系統(tǒng)中使用 ArangoDB 呢？它們都主要是文檔數(shù)據(jù)庫(kù)。
要始終考慮使用多種技術(shù)的維護(hù)和操作方面。
8. 人員的依賴(lài)性
這并非微服務(wù)特有的現(xiàn)象，但在微服務(wù)生態(tài)系統(tǒng)中卻變得更加普遍。原因是，大多數(shù)團(tuán)隊(duì)專(zhuān)注于他們的特定服務(wù)，因此他們并不了解完整的生態(tài)系統(tǒng)。在我與不同客戶(hù)的工作中，我發(fā)現(xiàn)，只有一群架構(gòu)師了解整體情況。但是，這些架構(gòu)師的問(wèn)題在于，他們并不積極參與日?；顒?dòng)，因此他們對(duì)開(kāi)發(fā)的影響力是有限的。
我認(rèn)為最好的辦法是，確保所有團(tuán)隊(duì)都有一個(gè)架構(gòu)團(tuán)隊(duì)的代表，這樣他們就可以使他們的團(tuán)隊(duì)與整個(gè)架構(gòu)團(tuán)隊(duì)的路線(xiàn)圖和目標(biāo)保持一致。要成為一個(gè)成熟的組織，你需要投資于建立一個(gè)輕量級(jí)的治理。
9. 文檔的缺乏
在過(guò)去幾年，我們接觸過(guò)的大多數(shù)組織都在文檔方面遇到困難。大多數(shù)開(kāi)發(fā)人員和架構(gòu)師要么不去編寫(xiě)文檔，要么編寫(xiě)的文檔毫無(wú)用處。即使他們想寫(xiě)，他們也不知道應(yīng)該如何記錄他們的架構(gòu)。
我們至少應(yīng)該記錄以下內(nèi)容：
- 設(shè)計(jì)文檔
- C4 模型中的上下文和容器圖
- 以架構(gòu)決策記錄的形式跟蹤關(guān)鍵架構(gòu)決策
- 開(kāi)發(fā)人員入門(mén)指南
我建議在版本控制系統(tǒng)中維護(hù)所有的文檔。
https://c4model.com/
http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
10. 功能超過(guò)平臺(tái)成熟度
在其他觀點(diǎn)中，我簡(jiǎn)要地提到了這個(gè)原因，但我認(rèn)為，它值得作為一個(gè)頂級(jí)原因來(lái)提及。微服務(wù)要比傳統(tǒng)的單體式應(yīng)用（monolithic application）更為復(fù)雜，因?yàn)槟阏跇?gòu)建一個(gè)包含許多活動(dòng)部件的分布式系統(tǒng)。大多數(shù)開(kāi)發(fā)人員還不了解系統(tǒng)的不同故障模式。大多數(shù)微服務(wù)在構(gòu)建時(shí)都考慮了令人快樂(lè)的路徑。因此，如果你的管理層只想僅僅關(guān)注功能，那么你注定會(huì)失敗。因?yàn)樵诒∪跗脚_(tái)上構(gòu)建的功能是無(wú)法提供價(jià)值的。
組織需要有平臺(tái)思維。平臺(tái)思維可不僅僅意味著使用容器和 Kubernetes。它們是解決方案的一部分，但本身并非完整的解決方案。你還需要考慮分布式跟蹤、可觀察性、混沌測(cè)試、函數(shù)調(diào)用與網(wǎng)絡(luò)調(diào)用、服務(wù)間通信的安全服務(wù)、可調(diào)試性等等。這需要在構(gòu)建正確的平臺(tái)和工具團(tuán)隊(duì)方面付出認(rèn)真的努力和投資。
如果你是一家資源有限的初創(chuàng)公司，我的建議是，你要重新考慮微服務(wù)戰(zhàn)略。了解你所面臨的問(wèn)題是什么。
11. 缺乏自動(dòng)化測(cè)試
大多數(shù)團(tuán)隊(duì)都知道自動(dòng)化測(cè)試對(duì)產(chǎn)品的整體質(zhì)量有多重要，但是他們?nèi)匀粵](méi)有做到。
微服務(wù)架構(gòu)為測(cè)試地點(diǎn)和測(cè)試方式提供了更多選擇。如果你不進(jìn)行徹底的自動(dòng)化測(cè)試，那么你將會(huì)失敗得很慘。關(guān)于這一點(diǎn)，我不會(huì)再贅述，因?yàn)榫W(wǎng)上很多人都寫(xiě)過(guò)這方面的內(nèi)容了。
下圖是我從微服務(wù)測(cè)試的文章找到的，這篇文章來(lái)自 Martin Fowler 的網(wǎng)站，討論了基于微服務(wù)的系統(tǒng)的測(cè)試金字塔。
微服務(wù)測(cè)試金字塔
網(wǎng)站標(biāo)題：了解微服務(wù)失敗的這11個(gè)原因，預(yù)防和及時(shí)止損！
分享鏈接：http://www.5511xx.com/article/dheegjh.html
