為什麼創業公司反而適合使用微服務+事件溯源？ -zimarev

banq發表於2021-03-15
創業微服務事件

為什麼推薦在創業公司中使用eventsourcing、dddesign和microservices微服務？
在過去的一年中，我參加了很多有關eventsourcing事件溯源的網路研討會，講座和講習班。很多時候觀眾回答一個問題：什麼時候使用這種模式？也就是說：在什麼情況下，事件驅動架構（EDA），面向服務的架構（SOA），CQRS等無法適用了？
我通常會告訴人們，當您真的不知道自己在做什麼的時候，使用事件溯源可能會引入不必要的複雜性。
 

早期軟體版本的質量
任何軟體的早期版本都具有許多變通辦法：各種駭客和捷徑方式。故意接受對質量的這種妥協就是我們所說的技術債務，這意味著需要償還利息。這種情況在創業公司是正常合理的，一家初創公司可以燒掉投資者的錢，然後開展業務，早期版本的軟體可能會破產，然後將債務登出。
牢記這一點，我們可以清楚地看到，花很多時間在軟體的技術優勢上，甚至可能永遠都不會使用，這沒有多大意義。
我不會在這裡談論EDA或事件源，因為我不認為應用這些模式從定義上可以使您的軟體更好。我想指出的是，領域驅動設計（DDD）並不是真正的軟體模式或體系結構，它可以為您節省數月的工作，尤其是在早期階段。那麼，DDD如何提供幫助呢？
假設創業的想法尚未得到正確驗證，我們甚至可能不知道我們要解決的問題是否相關。實際上，這就是DDD發光的區域。與您未來的客戶（使用者）的合作（這些客戶在DDD中稱為領域專家），可為您的客戶帶來大量寶貴見解：存在哪些困難以及如何解決他們的問題。與真正的客戶進行一些Event Storming會議肯定會改變您對域和提議的解決方案的看法。
話雖如此，我並不是要告訴您使用聚合，儲存庫或值物件。那不是重點。但是，您將能夠以純粹編寫軟體和討論團隊內進度的方式來檢視，理解和建模系統行為。
實際上，僅透過這樣做，就可以避免您的軟體最終破產！
設計不良的軟體（尤其是在創業環境中）的另一個問題是，第二階段永遠不會實現。原本打算成為技術債務本質上將成為負擔，您將沒有時間解決。為什麼？由於創業公司很少有能力花費時間來鞏固他們的系統，因為它們的工程能力有限，需要要花很多錢，而且積壓的產品也很厚，報廢寫得不好的五個版本的軟體是完全可以的，因為它不符合目的。當第六版取得成功時，它的編寫也將很糟糕，因為我們計劃也將其廢棄，但最終發現它很有用。
 

創業的事件溯源
有時，我會自己製作小型產品，以擺脫日常工作，並使我的技術和產品技能保持穩定。看起來像是一家初創公司，我敢肯定我的一些同事也會這樣做。
曾經，我建立了一個工作系統來支援我的度假物業租賃業務。它是一個整體，它使用文件資料庫來實現資料儲存的永續性。裡面有大量的變通辦法、硬編碼、常見的hack。
在這種情況下，我也是一個領域專家，因為我確切地知道我想解決什麼問題，僅因為這些是我自己的問題。在這方面，我還不能說這是一個乾淨的實驗，因為您很少會從潛在客戶那裡獲得對問題空間的這種瞭解。儘管如此，足以稱呼它為實驗室。
 

模型是錯誤的
之後，我發現我的域模型是錯誤的。我沒有花足夠的時間來建模各種場景上下文，只專注於最明顯的場景上下文。
當我找到一個更好的模型時，我發現自己被構建的系統所困擾。怎麼會這樣 僅僅因為我所擁有的只是資料庫中的一堆文件，代表了當前的系統狀態。由於模型不正確，因此狀態本身雖是正確的，但是沒有足夠的資料。也可以說該模型不是完全錯誤的，但是它缺少一個重要的上下文，我甚至不知道它為什麼存在。
我當時意識到的是今天我清楚記得的事情。我的系統的行為是正確的。我所擁有的所有命令都是有效且有用的。但是，當我使用基於狀態的永續性時，我沒有明確捕獲行為，而是更新了系統狀態，因為我們幾乎在所有地方都“預設”了。對於新模型，我需要對該行為進行不同的表示，以另一種狀態表示。所以，這是我學到的東西：

從行為重構狀態非常容易。從某種狀態對行為進行逆向工程非常困難，有時甚至是不可能的。
這是狀態示例，即MongoDB中的Booking狀態：

{
    "_id": "ac2fd0edd2d74f249afea3f9014934ad",
    "amount": "5600",
    "bookingChannel": "booking.com",
    "checkInDate": [{"$numberLong": "637498908000000000"}, 0],
    "checkOutDate": [{"$numberLong": "637500636000000000"}, 0],
    "externalBookingNumber": "2955008750",
    "guest": {
        "name": "Ole Nordmann",
        "email": "ole.fake0@brooking.me",
        "phone": "+78123123123"
    },
    "paidInFull": false,
    "prepaid": false,
    "property": {
        "_id": "0392c950d8ea4840850d098af0de12df",
        "name": "Great Apartment"
    }
}


最終發現，當我需要檢查一個新預訂的可用性時，僅檢查該房間將來的所有預訂都非常困難。而且，如果您處理房間類別而不是單個房間，則將變得更加困難。我需要一個叫做Day日期的東西，這個概念可以在許多領域中找到，它涉及排程。
如果我的系統從第一天開始就是事件源的，那麼我可以刪除並重建系統狀態，或者透過編寫新的讀取模型投影非常容易地引入狀態的新表示。我可以將它們與當前正在執行的生產系統分開建立，並且仍然使用生產資料，因為它甚至不會影響任何已經可用的資料。
... 

微服務
現在，我想談一談SOA。
在我提到的系統中，目前有四個服務：

  • 後臺辦公
  • 訪客門戶
  • 訊息傳遞
  • 日曆供稿同步

我將這些子系統拆分為單獨的服務的原因非常明顯。它們有著完全不同的關注點，儘管其中一些可能是多上下文服務，但我可以清楚地將它們識別為有界的上下文。
我可以將它們全部建成一個整體嗎？是的，為什麼不？會更容易維護嗎？但是我不會。
首先，當其中只有一部分發生更改時，我不想部署整個元件。後臺辦公服務對我來說是適當的管理者。它具有身份驗證和授權位，不適用於任何其他元件。我也隨時可以自由部署它，因為它只會影響我。在訪客嘗試辦理登機手續時（或更糟糕的是，在付款會話的中間），可能會部署訪客入口網站。在沒有適當的部署策略的情況下部署訊息服務可能會導致訊息丟失，因此我必須始終有至少一個例項在執行。
其次，我覺得在上下文相關的軟體上工作會更好。它並不會給我造成太多的認知超負荷，因為我確切地知道它會做什麼以及我需要如何做。在整體/單體系統中，我經常發現自己被拖離了最初的任務，因為我開始注意到其他不相關的事物，這些事物我想“順便”解決。
 

結論
正如我前面提到的，在創業環境中處理事件源，DDD，微服務等可能對您來說不是一件容易的事。如果您沒有很多經驗，但是又不在一開始創業就這麼做，您將永遠無法獲得這些知識的經驗……
隨著我更加熟練地應用這些模式，並且對DevOps部分更加滿意，我不再擔心所謂的意外複雜性。
我一直看到的是：系統是由那些難以集中精力的團隊以及不斷爭論著無休止的依賴關係的團隊在沒有任何模型的情況下使用整體資料庫構建的。
對於我來說，我寧願構建一個事件源、事件驅動的系統，將其分成幾個微服務，尤其是在初創公司中！




 

相關文章