反模式是隨著項目的推進演變而來的，主要的原因，如重大需求調整，但架構沒有對應的變化，性能和安全需求對當前架構的硬性改變，團隊或組織強行調整技術等。本文將為大家講解雲原生架構中常見的反模式。
龐大的單體應用
如果你有過維護或者開發巨型單體應用的經歷，肯定遇到過諸多令人痛苦的問題，比如，Git 倉庫過於龐大、IDE 打開慢、編譯慢、應用啟動慢、依賴的服務太多……對於新人來說，能夠將代碼複製下來，並且編譯成功，能正常啟動應用，那將是極其幸運的事情。更多的情況則是，運維人員至少要花費 1 到 2 周的時間去了解這個龐大的應用，否則基本上無法開始編寫代碼。這裡並不是要排斥巨型單體應用，其還是有適用場景的。我們也不想討論什麼情況下不適合使用微服務之類的話題，這些都需要根據實際情況做出合理的決策。但是，對於大多數業務場景來說，微服務架構是非常合適的。
單體應用“硬拆”為微服務
應用的劃分是一套非常科學的方法論。正如庖丁解牛一樣，只有瞭解了系統的原理，擺脫一刀切的思維，我們才能做到遊刃有餘。最核心的還是領域驅動設計（Domain-DrivenDesign，DDD）的劃分思想。
DDD 的本質是根據業務屬性將系統劃分為不同的業務領域，最簡單的如電商系統中的會員、商品、交易和物流等。為了配合這些業務的運行，我們需要一些支持系統，如 CMS、社交運營平臺等。如果涉及個性化推薦的商業需求，大數據和 AI 平臺也是必不可少的。
依據 DDD 的 Domain 原則劃分子域後，我們會使用 Bounded Context 來實現這些子域的落地。目前，我們可以將 Bounded Context 理解為微服務應用，多個 Bounded Context 可以共同支持一個子域，從而共同實現子域需要的業務功能。DDD 提供了非常完善的 Bounded Context 之間的關聯關係和通信機制。例如，最新的 DDD + Reactive 模式就是將異步化和事件驅動的設計思想帶到了微服務架構設計中。
DDD 的子域主要分為三種類型，分別為核心子域、普通子域和支持子域。其中，普通子域和支持子域就是我們常說的通用類子域，具體業務形態體現為 SaaS 服務，或者雲廠商提供的技術產品，如業務相關的經銷存管理系統、CRM 管理系統、社交營銷平臺等，技術產品如應用性能監控、圖片識別服務、數據分析平臺等。在項目研發的前 / 中期，建議考慮整合第三方或者雲廠商提供的普通子域和支持子域服務，將重心放在業務核心子域，不能 因為受到普通子域和支持子域開發進度、特性不完善等問題的影響，而造成核心子域上線延遲、功能缺失等問題，待項目後期再考慮是否自主實現普通子域和支持子域服務。這方面已有不少成功案例值得參考，很多支持核心業務的通用服務伴隨著商業項目的發展也取 得了成功，如亞馬遜的 AWS 雲服務。
缺乏自動化能力的微服務
當微服務應用數量較小的時候，我們還能以手動的方式維護系統。但是，當應用數量變得比較龐大時，再採用手動維護的方式已經不大可能，我們需要依靠自動化的方式來 管理大量的微服務應用。應用的自動化管理會涉及很多方面，如編譯、部署和監控。目前，大多數 PaaS 平臺和雲廠商提供的服務基本上具備自動化能力。通常，我們不用自己開發， 只需要對接即可， 或者只需要進行少量的配置， 或者添加一些相關的監控埋點等。
對於開發來說，市面上已有很多支持測試自動化的框架，比如 CI/CD、IaaS、各種便捷的 Kubernetes 命令工具和服務類 API，如自動化測試環境的 Testcontainer、測試數據自動化的 Database Rider、模擬 HTTP REST API 的 Hoverfly-Java 等，都有助於快速完成自動化。但我們認為構建自動化能力的關鍵在於團隊是否有這樣的意識，而不是對應的技術產品是否完善。如果團隊決定採用微服務架構，那麼最好能夠提前考慮關於微服務的自動化 能力，統一規劃，這樣即便在後期面對微服務應用數量激增、技術棧不統一的情況，也不會忙中出錯。當開發人員同時投入 3 到 5 個微服務應用的開發和維護時，想要在不同的應用之間快速切換且不出現錯誤，則是非常困難的。所以一定要銘記，對於微服務來說，自動化的 CI/CD 是最低的要求。
架構不能充分使用雲的彈性能力
雲計算服務架構主要可劃分為三層，分別是 IaaS、PaaS和 SaaS，如圖所示。
雲計算服務架構
IaaS 位於最底層，提供服務器、存儲、網絡等服務。這些都屬於基礎設施，例如雲服務器、存儲服務等。PaaS 位於 IaaS 之上，是對 IaaS 資源的進一步抽象，基本屏蔽了 IaaS 層的細節，例如 Kubernetes 就屬於這一層。SaaS 位於最高層，直接提供服務及服務對接，例如 OpenAPI 集成、調用阿里雲短信發送服務等，都屬於 SaaS 層提供的服務。
從理論上講，我們最好能直接對接 SaaS 層提供的服務，至於服務器、存儲以及資源擴展，全部交由 SaaS 廠商負責。對於 PaaS 層，由於我們需要開發自己的內部應用，會涉及應用部署之類的問題，因此該層的自動化（如資源的自動管理）通常都做得比較好。如果考慮彈性擴容能力，最好是基於 PaaS 平臺進行。IaaS 層的彈性擴容是比較難的，不能隨意購買雲服務器和存儲，購買這些資源後則需要進行一系列的工作，如對環境初始化、設置 Ops 監控系統、部署應用以及上線應用。
技術架構與組織能力不匹配
應用微服務化之後，會有更多的小團隊負責不同的微服務應用，可能需要重新組建管理團隊、開發團隊和基礎設施運維團隊，由此可能會帶來組織結構和管理方式的調整。
其中的一個變化是團隊管理更趨於扁平化。在開發和維護巨型應用時，每個人只會集中於某一個模塊。在進行大型應用的需求變更和新特性開發之前，開發人員都會經過一套標準的流程，即評估、任務分解、安排開發進度等。而且開發人員最瞭解模塊，可以保證流程都是可控的，最後經過完善的測試後整體上線。當然，微服務應用也會隨著商業需求的變化而調整，但這個過程不再是大團隊一起配合、一起上線，更有可能的是，特性的開發和新功能的調整分階段進行開發和上線。由於在不同的微服務之間存在不同的服務規約，因此可以逐步開發和上線。我們可以將這種分階段理解為一種“小步快跑”的研發節奏。當然，大型應用也可以採用“小步快跑”的方式。
對於開發團隊來說，應用微服務化後，每個服務都會變得更聚焦，體量更小。但“麻雀雖小，五臟俱全”，微服務同樣要求我們擁有更多的知識。在這個過程中，我們可以尋求團隊中其他人的幫助，但這勢必會產生溝通成本，降低研發效率，所以要有能力解決 90% 的問題。另外，微服務化更強調單兵作戰的能力。微服務架構是多語言、多技術棧的架構，雖然不需要我們深入瞭解每一個微服務的編程語言和技術棧，但要求至少掌握相應的開發技術。如 Java 程序員切換到 Node.js 應用時，不需要了解 Node.js 的底層知識（如 V8、EventLoop 等），只要理解 JavaScript 語法、模塊管理、Promise 和 Async/Await 等，基本上就可以正常維護一個 Node.js 微服務應用了。這些變化可能給開發團隊帶來新的挑戰，至少團隊成員需要學習和了解的知識要比以前更多。
為了更好地配合開發團隊，基礎設施運維團隊需要獲得更好的 PaaS 服務（如基於Kubernetes 二次開發，或者雲廠商提供的 PaaS 平臺）。只有有了充足的保證，運維團隊才能工作得更快、更好。
更多信息
《阿里云云原生架構實踐》由阿里雲官方出品，阿里雲智能總裁張建鋒、阿里巴巴首席技術官程立聯袂推薦；從設計原則、模式/反模式、技術選項、設計方法、行業案例等多個維度全面總結阿里云云原生架構的方法論和實踐經驗。
現在開放 5 折限時優惠，可直接點擊https://item.jd.com/13295448.html購買。
