3.3 微服務(wù)構(gòu)建進(jìn)階

本節(jié)我們將從更宏觀的軟件構(gòu)建視角切入來總結(jié)微服務(wù)構(gòu)建的最佳實(shí)踐，宗旨是指導(dǎo)開發(fā)者合理地設(shè)計(jì)和構(gòu)建可演進(jìn)式的系統(tǒng)架構(gòu)。

3.3.1 軟件構(gòu)建

軟件構(gòu)建通常是指軟件的詳細(xì)架構(gòu)設(shè)計(jì)、編碼、調(diào)試、測試和集成等方面的工作。作為軟件開發(fā)的主要組成部分，軟件構(gòu)建依然是軟件開發(fā)工程的核心活動，它在整個軟件開發(fā)交付周期中大概占到30%～80%的時間。

下圖是經(jīng)過幾十年的實(shí)踐積累，研究人員給出的軟件開發(fā)過程中各種不同關(guān)鍵活動的時間順序。

上述活動獨(dú)立拿出來都可以作為軟件工程中的主題加以討論，而“軟件構(gòu)建”作為軟件開發(fā)中的核心活動顯然具有更重要的地位。

軟件構(gòu)建要重視代碼質(zhì)量，因?yàn)樵创a是軟件唯一的精準(zhǔn)描述和最終產(chǎn)物，敏捷的開發(fā)流程也強(qiáng)調(diào)可閱讀的代碼大于規(guī)格文檔的理念。源碼可以增強(qiáng)軟件工程的可管理性，源碼的質(zhì)量和可讀性是決定軟件能否持續(xù)演進(jìn)的重要因素。

軟件構(gòu)建使用高層架構(gòu)設(shè)計(jì)指導(dǎo)系統(tǒng)的編程開發(fā)約束。高質(zhì)量的架構(gòu)可以使構(gòu)建活動更加容易，使復(fù)雜的系統(tǒng)分解成為可管理、獨(dú)立、層次化的軟件集合；而糟糕的架構(gòu)設(shè)計(jì)將使你的構(gòu)建活動舉步維艱、困難重重，嚴(yán)重影響系統(tǒng)的后期維護(hù)和擴(kuò)展。下圖是我們總結(jié)的高質(zhì)量架構(gòu)原則。

3.3.2 微服務(wù)構(gòu)建實(shí)踐

微服務(wù)構(gòu)建傾向于使用領(lǐng)域驅(qū)動設(shè)計(jì)模式，從技術(shù)實(shí)現(xiàn)的層面遵循并實(shí)踐高質(zhì)量的軟件架構(gòu)原則，目標(biāo)是持續(xù)快速地滿足業(yè)務(wù)需求，支撐靈活的軟件工程流程，實(shí)現(xiàn)成本可控及高效的價(jià)值交付。我們可以將業(yè)務(wù)目標(biāo)、高質(zhì)量軟件架構(gòu)原則、微服務(wù)構(gòu)建實(shí)踐三者的關(guān)系表述如下圖所示。

如果對微服務(wù)構(gòu)建實(shí)踐從時間維度做進(jìn)一步細(xì)化，我們可以將其劃分為微服務(wù)架構(gòu)定義、架構(gòu)落地、規(guī)?；l(fā)展三個階段設(shè)計(jì)。

在微服務(wù)架構(gòu)定義階段，我們使用領(lǐng)域驅(qū)動設(shè)計(jì)的方法論來完成對業(yè)務(wù)的建模及服務(wù)邊界的接口定義。與傳統(tǒng)的基于技術(shù)實(shí)現(xiàn)的分層架構(gòu)模式不同，領(lǐng)域驅(qū)動設(shè)計(jì)更加關(guān)注業(yè)務(wù)，它在實(shí)際業(yè)務(wù)場景中通過業(yè)務(wù)邊界的識別對領(lǐng)域服務(wù)進(jìn)行界限劃分；微服務(wù)架構(gòu)強(qiáng)調(diào)功能職責(zé)單一、圍繞業(yè)務(wù)組織團(tuán)隊(duì)、輕量級的集成交互機(jī)制等特性，都與領(lǐng)域驅(qū)動設(shè)計(jì)模式概念高度一致、不謀而合。

在微服務(wù)架構(gòu)落地階段，需要一個具備承載業(yè)務(wù)、簡單生產(chǎn)就緒的軟件底座技術(shù)來啟動和運(yùn)行我們的業(yè)務(wù)服務(wù)，在技術(shù)選型上，Spring Boot基于約定優(yōu)于配置的編程范式，可以極大地提升軟件開發(fā)人員的工作效率。同時成熟的社區(qū)支持、廣大的開發(fā)群體、全面完整的技術(shù)框架支撐都是Spring Boot成為微服務(wù)架構(gòu)落地的首選技術(shù)棧。

在微服務(wù)架構(gòu)規(guī)模化發(fā)展階段，服務(wù)治理成為解決系統(tǒng)復(fù)雜性、可用性、可觀測性、可靠性、容錯性、關(guān)注點(diǎn)分離的關(guān)鍵技術(shù)。在技術(shù)選型上，我們使用Spring Cloud技術(shù)生態(tài)作為微服務(wù)的治理體系。此外，服務(wù)集成交互機(jī)制、后端數(shù)據(jù)一致性、容器技術(shù)、持續(xù)集成、持續(xù)交付、監(jiān)控治理都是微服務(wù)構(gòu)建和規(guī)模化管理需要重點(diǎn)關(guān)注的技術(shù)領(lǐng)域。

微服務(wù)架構(gòu)的發(fā)展趨勢是將更多的公共組件、模塊能力、橫切關(guān)注點(diǎn)下沉到基礎(chǔ)設(shè)施。軟件構(gòu)建的復(fù)雜性從業(yè)務(wù)層轉(zhuǎn)移到基礎(chǔ)設(shè)施層，通過將業(yè)務(wù)代碼與技術(shù)架構(gòu)解耦，實(shí)現(xiàn)業(yè)務(wù)價(jià)值的快速交付。

3.3.3 微服務(wù)架構(gòu)反模式

前面介紹了微服務(wù)的一些好的設(shè)計(jì)模式和實(shí)踐，下面列舉一些微服務(wù)架構(gòu)的反模式，這樣我們可以在微服務(wù)構(gòu)建過程中更好地進(jìn)行取舍。

微服務(wù)劃分粒度越小越好

微服務(wù)粒度的大小并沒有統(tǒng)一的業(yè)界標(biāo)準(zhǔn)，并非越小越好。服務(wù)劃分的主要依據(jù)是業(yè)務(wù)屬性，組織層級、團(tuán)隊(duì)規(guī)模、代碼規(guī)模、業(yè)務(wù)復(fù)雜度都對服務(wù)粒度劃分產(chǎn)生影響。

內(nèi)聚不相關(guān)功能服務(wù)

服務(wù)必須清楚地與業(yè)務(wù)能力保持一致，不應(yīng)該試圖做一些超出范圍的事。功能隔離問題對架構(gòu)治理而言至關(guān)重要，否則它會破壞敏捷性、性能和可擴(kuò)展性，導(dǎo)致創(chuàng)建一個緊耦合、無法擴(kuò)展演進(jìn)的架構(gòu)。

不重視自動化

隨著微服務(wù)規(guī)模的擴(kuò)大，自動化集成和交付成為微服務(wù)交付的關(guān)鍵。微服務(wù)的目標(biāo)是驅(qū)動敏捷，為我們提供所需的自動化工具。

服務(wù)架構(gòu)分層

團(tuán)隊(duì)過度關(guān)注技術(shù)層面的內(nèi)聚，而不是功能相關(guān)的重用。這樣會形成一個由橫向團(tuán)隊(duì)管理的人造物理層，導(dǎo)致交付依賴。

手動配置環(huán)境

當(dāng)我們創(chuàng)建的服務(wù)越來越多時，服務(wù)的配置管理會面臨失控的風(fēng)險(xiǎn)。大部分生產(chǎn)部署不順利的情況都是由于配置錯誤造成的，手動管理配置信息在微服務(wù)架構(gòu)下將變得越來越困難。

未使用版本控制

在微服務(wù)的世界里，復(fù)雜度會隨著服務(wù)數(shù)量的增加而增加。制定一個版本控制策略可以使服務(wù)的消費(fèi)者輕松遷移，并且服務(wù)提供者可以透明地部署變更而不產(chǎn)生級聯(lián)影響。

缺少API網(wǎng)關(guān)

每個服務(wù)都要單獨(dú)實(shí)現(xiàn)鑒權(quán)、過濾等功能，正確的做法是集中管理和監(jiān)控部分非功能性問題。API網(wǎng)關(guān)可以編排跨功能的微服務(wù)，同時實(shí)現(xiàn)共享服務(wù)的復(fù)用。

服務(wù)依賴第三方系統(tǒng)

當(dāng)服務(wù)依賴第三方系統(tǒng)時，服務(wù)就不是松耦合的了。要讓服務(wù)有獨(dú)立性，交付的每個服務(wù)都必須具備獨(dú)立的測試套件。