企業(yè)架構設計的痛點分析

1、企業(yè)架構設計的痛點分析本文給出了軟件架構演化過程中出現(xiàn)的4種經(jīng)典架構，就每種架構，分析了其主要特點并在幾個度量維度給出結論。在文章的最后給出了4種架構的多維對比。1 分層架構分層架構是最常見的架構，也被稱為n層架構。多年以來，許多企業(yè)和公司都在他們的項目中使用這種架構，它已經(jīng)幾乎成為事實標準，因此被大多數(shù)架構師、開發(fā)者和軟件設計者所熟知。分層架構中的層次和組件是水平方向的分層，每層扮演應用程序中特定的角色。根據(jù)需求和軟件復雜度，我們可以設計N層，但大多數(shù)應用程序使用3-4層。有太多層的設計會很糟糕，將導致復雜度的上升，因為我們必須維護每一層。在傳統(tǒng)的分層架構中，分層包括表現(xiàn)層、業(yè)務或者服務層，

2、以及數(shù)據(jù)訪問層。 表現(xiàn)層負責應用程序的用戶交互和用戶體驗（外觀和視覺）。通常我們會使用數(shù)據(jù)傳輸對象（Data Transfer Object）將數(shù)據(jù)帶到這一層，然后使用視圖模型（View Model）渲染到客戶端。業(yè)務層接收請求并執(zhí)行業(yè)務規(guī)則。數(shù)據(jù)訪問層負責操作各種類型的數(shù)據(jù)庫，每個訪問數(shù)據(jù)庫的請求都要經(jīng)過這一層。分層無需知道其他層如何去做，比如業(yè)務層無需知道數(shù)據(jù)訪問層是如何查詢數(shù)據(jù)庫的，相反，業(yè)務層在調(diào)用數(shù)據(jù)層的特定方法時，只需關注需要部分數(shù)據(jù)還是全部數(shù)據(jù)。這就是我們所說的關注點分離。這是非常強大的功能，每層負責其所負的責任。分層架構中的核心概念是管理依賴。如果我們使用依賴倒置原則和測試驅動

3、開發(fā)(Test Driven Development)，我們的架構會有更好的健壯性。因為，我們要保證所有可能的用例都有測試用例。我們需要這樣的冗余，即使業(yè)務層沒有處理業(yè)務規(guī)則，也要通過業(yè)務層來調(diào)用數(shù)據(jù)層，這叫分層隔離。對于某些功能，如果我們從表現(xiàn)層直接訪問數(shù)據(jù)層，那么數(shù)據(jù)層后續(xù)的任何變動都將影響到業(yè)務層和表現(xiàn)層。分層架構中的一個重要的概念就是分層的開閉原則。如果某層是關閉的，那么每個請求都要經(jīng)過著一層。相反，如果該層是開放的，那么請求可以繞過這一層，直接到下一層。分層隔離有利于降低整個應用程序的復雜度。某些功能并不需要經(jīng)過每一層，這時我們需要根據(jù)開閉原則來簡化實現(xiàn)。分層架構是SOLID原則的通

4、用架構，當我們不確定哪種架構更合適的時候，分層架構將是一個很好的起點。我們需要注意防止架構陷入污水池反模式。這種反模式描述了請求經(jīng)過分層，但沒做任何事或者只處理了很少的事。如果我們的請求經(jīng)過所有分層而沒有做任何事，這就是污水池反模式的征兆。如果20%的請求只是經(jīng)過各層，而80%的請求實際做事，這還好，如果這個比率不是這樣的，那么我們已經(jīng)患上反模式綜合征。此外，分層架構可以演變?yōu)榫奘瘧茫∕onolith），導致代碼庫難以維護。分層架構分析：敏捷性：總體敏捷性是指對不斷變化的環(huán)境作出反應的能力。由于其整體風格（Monolith）的性質(zhì)，可能會變得難以應對通過所有層的變化，開發(fā)者需要注意依賴性和分

5、層分離。易于部署：大型應用程序的部署會是個麻煩。一個小要求，可能需要部署整個應用程序。如果能做好持續(xù)交付，可能會有所幫助?？蓽y試性：使用Mocking和Faking，每一層可以獨立測試，因此測試上很容易。性能：雖然分層應用程序可能表現(xiàn)良好，但是因為請求需要經(jīng)過多個分層，可能會存在性能問題?？缮炜s性：因為耦合太緊以及整體風格（Monolith）的天生特質(zhì)，很難對分層應用程序進行伸縮。然而，如果分層能夠被構建為獨立的部署，還是可以具備伸縮能力的。但是，這樣做的代價可能很昂貴。易于開發(fā)：這種模式特別易于開發(fā)。許多企業(yè)采用這種模式。大多數(shù)開發(fā)者也都知道、了解，并且可以輕松學習如何使用它。2 事件驅動架

6、構事件驅動架構（Event Driven Architecture）是一種流行的分布式異步架構模式，用于創(chuàng)建可伸縮的應用程序。這種模式是自適應的，可用于小規(guī)模或者大規(guī)模的應用程序。事件驅動架構可以與調(diào)停者拓撲（Mediator Topology）或者代理者拓撲（Broker Topology）一起使用。理解拓撲的差異，為應用程序選擇正確的拓撲是必不可少的。調(diào)停者拓撲調(diào)停者拓撲需要編排多種事件。比如在交易系統(tǒng)中，每個請求流程必須經(jīng)過特定的步驟，如驗證、訂單、配送，以及通知買家等。在這些步驟中，有些可以手動完成，有些可以并行完成。通常，架構主要包含4種組件，事件隊列（Event Queue）、調(diào)停

7、者（Mediator）、事件通道（Event Channel）和事件處理器（Event Processor）?？蛻舳藙?chuàng)建事件，并將其發(fā)送到事件隊列，調(diào)停者接收事件并將其傳遞給事件通道。事件通道將事件傳遞給事件處理器，事件最終由事件處理器處理完成。事件調(diào)停者不會處理也不知道任何業(yè)務邏輯，它只編排事件。事件調(diào)停者知道每種事件類型的必要步驟。業(yè)務邏輯或者處理發(fā)生在事件處理器中，事件通道、消息隊列或者消息主題用于傳遞事件給事件處理器。事件處理器是自包含和獨立的，解耦于架構。理想情況下，每種事件處理器應只負責處理一種事件類型。通常，企業(yè)服務總線、隊列或者集線器可以用作事件調(diào)停者。正確選擇技術和實現(xiàn)能夠降

8、低風險。代理者拓撲不像調(diào)停者拓撲，代理者拓撲不使用任何集中的編排，而是在事件處理器之間使用簡單的隊列或者集線器，事件處理器知道處理事件的下一個事件處理器。因其分布式和異步的性質(zhì)，事件驅動架構的實現(xiàn)相對復雜。我們需要面對很多問題，比如網(wǎng)絡分區(qū)、調(diào)停者失敗、重新連接邏輯等。由于這是一個分布式且異步的模式，如果你需要事務，那就麻煩了，你得需要一個事務協(xié)調(diào)器。分布式系統(tǒng)中的事務非常難以管理，很難找到標準的工作單位模式。另一個充滿挑戰(zhàn)的概念是契約。架構師聲稱服務的契約應該預先定義，而應變是非常昂貴的。事件驅動架構分析：敏捷性：由于事件和事件處理器之間解耦，并且可獨立維護，因此這種模式的敏捷性很高。變化可

9、以快速、輕松地完成，而不會影響整個系統(tǒng)。易于部署：由于架構是解耦的，因此很容易部署。組件可以獨立部署，并且可以在調(diào)停者上注冊。部署在代理者拓撲上也相當簡單?？蓽y試性：雖然獨立測試組件很容易，但測試整個應用程序很有挑戰(zhàn)。因此端到端的測試是很難的。性能：事件驅動架構性能非常好，因為它是異步的。此外，事件通道和事件處理器可以并行工作，因為它們是解耦的?？缮炜s性：事件驅動架構的伸縮性非常好，因為組件之間解耦，組件可以獨立擴展。易于開發(fā)：這種架構的開發(fā)不是很容易。需要明確定義契約，錯誤處理和重試機制得處理得當。3 微內(nèi)核架構微內(nèi)核架構（Microkernel architecture）模式也被稱為插件架

10、構（plugin architecture）模式。這是產(chǎn)品型應用程序的理想模式，由兩部分組成：核心系統(tǒng)和插件模塊。核心系統(tǒng)通常包含最小的業(yè)務邏輯，并確保能夠加載、卸載和運行應用所需的插件。許多操作系統(tǒng)使用這種模式，因此得名微內(nèi)核。插件彼此獨立，因此解偶。核心系統(tǒng)持有注冊器，插件將自己注冊其上，因此核心系統(tǒng)知道哪里可以找到它們以及如何運行它們。這種模式非常適合桌面應用程序，但是也可以在Web應用程序中使用。事實上，許多不同的架構模式可以作為整個系統(tǒng)的一個插件。對于產(chǎn)品型應用程序來說，如果我們想將新特性和功能及時加入系統(tǒng)，微內(nèi)核架構是一種不錯的選擇。微內(nèi)核架構分析：敏捷性：由于插件可以獨立開發(fā)并注

11、冊到核心系統(tǒng)，微內(nèi)核架構具有很高的敏捷性。易于部署：依賴于核心系統(tǒng)的實現(xiàn)，能做到不需要重新啟動整個系統(tǒng)來完成部署?？蓽y試性：如果插件開發(fā)是獨立的，測試就可以獨立且隔離地進行。還可以Mock核心系統(tǒng)來測試插件。性能：這取決于我們有多少插件在運行，但性能可以調(diào)優(yōu)?？缮炜s性：如果整個系統(tǒng)被部署為單個單元，這個系統(tǒng)將難以擴展。易于開發(fā)：這種架構不容易開發(fā)。實現(xiàn)核心系統(tǒng)和注冊會很困難，而且插件契約和數(shù)據(jù)交換模型增加了難度。4 微服務架構盡管微服務的概念還相當新，但它確實已經(jīng)快速地吸引了大量的眼球，以替代整體應用和面向服務架構（SOA）。其中的一個核心概念是具備高可伸縮性、易于部署和交付的獨立部署單元（S

12、eparately Deployable Units）。最重要的概念是包含業(yè)務邏輯和處理流程的服務組件（Service Component）。拿捏粒度設計服務組件是必要而具有挑戰(zhàn)性的工作。服務組件是解耦的、分布式的、彼此獨立的，并且可以使用已知協(xié)議來訪問。微服務的發(fā)展是因為整體應用和面向服務應用程序的缺陷。整體應用程序通常包含緊耦合的層，難以部署和交付。比如，如果應用程序總在每次應對變化時垮掉，這是一個因耦合而產(chǎn)生的大問題。微服務將應用程序分解為多個部署單元，因此很容易提升開發(fā)和部署能力，以及可測性。雖然面向服務架構非常強大，具有異構連接和松耦合的特性，但是性價比不高。它很復雜、昂貴，難于理解和實現(xiàn)，通常對于大多數(shù)應用程序來說矯枉過正。微服務簡化了這種復雜性?？绶战M件的代碼冗余是完全正常的。開發(fā)微服務時，為了受益于獨立的部署單元，以及更加容易的部署，我們可以違反DRY原則。其中的挑戰(zhàn)來自服務組件之間的契約，以及服務組件的可用性。微服務架