7.3 業務問題
7.3.1 陷阱： 產品定製
銷售人員希望軟件可以無限定製。
爲每個客戶定製
永久的功能開關
產品驅動定製化
7.3.2 反模式： 報表
報表是單體架構中意外耦合的好例子。架構師和 DBA 想使用相同的數據庫模式來支持記
錄和報表系統，但問題是，這種設計既無法優化記錄系統，也無法優化報表系統。
7.3.3 陷阱： 規劃視野
預算和規劃流程通常決定了對假設和早期決策（假設的基礎）的需求。然而，不去重新審
視計劃，規劃範圍越大意味着更多決策（或假設）是基於最少量的信息制定的。
8,實踐演進式架構
實現演進式架構相關想法所需的工作。
8.1 組織因素
8.1.1 全功能團隊
以領域爲中心的團隊應該是全功能的，這意味着每個項目角色都由該項目組成員承擔。
業務分析師,架構師,測試人員,運維人員，數據人員
8.1.2 圍繞業務能力組織團隊
按照業務能力而非職能來組織團隊。
8.1.3 產品高於項目
圍繞產品而非項目來組織團隊工作
公司能在三個方面實現轉變。第一，與項目的生命週期不同，產品
的生命更長久。全功能團隊（通常基於康威逆定律）與產品保持聯繫。第二，每個產品都
有一個負責人，他會主張在體系中使用該產品，並管理其需求。第三，由於是全功能團
隊，團隊擁有產品所需的各種角色，例如業務分析師、開發人員、質量保障人員、 DBA、
運維人員等
8.1.4 應對外部變化
構建適應度函數來保護架構中的維度免於演進副作用的影響。
8.1.5 團隊成員間的連接數
構建小型團隊是爲了減少溝通連接。並且，爲了消除
不同團隊間協作所產生的人爲摩擦，這些小型團隊需要是全功能團隊。
8.2 團隊的耦合特徵
8.2.1 文化
好的架構師會擔任領導角色，爲開發人員
構建系統確立技術文化和設計方法。
架構師能通過提下列問題了解團隊的工程文化。
1是否團隊所有人都知道什麼是適應度函數，並考慮了新工具或產品選型對演進新適應度
函數的影響？
2.團隊是否衡量了系統與所定義的適應度函數的匹配程度？
3.工程師是否理解內聚和耦合？
4.是否討論了什麼領域和技術概念該整合到一起？
5.團隊是基於變更能力還是基於他們想學習的技術來選擇解決方案的？
6.團隊對業務變更如何做出反應？他們是否難於完成小的變更，或在小的業務變更上花費
了太多時間？
8.2.2 試驗文化
成功的演進離不開試驗
組織可以通過如下幾種方式鼓勵試驗。
1從外部吸收想法
2，鼓勵明確的改進
3進行探針試驗並穩定下來
4創造創新時間
5 採用基於集合的開發方式
6連接工程師和最終用戶
8.3 首席財務官和預算
在演進式架構中，企業架構的一些傳統功能必須反映不斷變化的優先級，例如預算
在演進式架構中，架構師追求合適的量子大小和對應成本之間的最佳點。
8.4 構建企業適應度函數
在演進式架構中，企業架構師的工作主要圍繞着架構指導和企業級適應度函數展開。
演進式架構賦予企業架構師的另一個新職責是定義企業級適應度函數
8.5 從何開始
一些構建演進式架構實踐的相關通用策略和理由。
8.5.1 容易實現的目標
如果組織需要早期成功來證明這種方法，架構師可以選擇最簡單的問題來凸顯演進式架構
方法。
8.5.2 最高價值優先
找到系統中最關鍵的部分，圍繞它構建演進行爲。
第一，如果架構師確信要實現
演進式架構，那麼選擇價值最高的部分就表明了決心。第二，對於那些仍在評估想法的公
司，他們的架構師可能對這些技術在體系中的適用性感興趣。因此優先選擇價值最高的部
分，便能明確演進式架構的長遠價值。第三，如果架構師懷疑這些方法的適用性，那麼用
系統中最有價值的部分來審查這些概念，能夠爲是否繼續提供了可行的數據。
8.5.3 測試
對演進式架構的增量變更而言，測試是關鍵的組件，並且適應度函數也在積極地利用測
試。
8.5.4 基礎設施
對那些基礎設施功能失調的公司來說，構建演進式架構之前可能需要先解決這些問題。
1運維工作外包給別的公司，因此無法控制其體系的關鍵部分。
2開發和運維之間無法穿透的防火牆
3架構師和開發人員都忽視好的實踐
8.6 演進式架構的未來
幾個前景方向
8.6.1 基於AI的適應度函數
8.6.2 生成式測試
8.7 爲什麼（不） 呢
8.7.1 公司爲何決定構建演進式架構
每個公司都必須具備軟件開發和交付能力
1. 可預測性與可演進性
軟件開發領域易變的本質將所有組織推向增量變更。
2. 規模
3. 高級業務能力
在面對不可避免又
無法預測的變化時，演進性架構能賦予公司更好的技術響應能力。
4. 以生產週期爲業務指標
生產週期已經成爲了一種業務差異。一些大型傳統組織將軟件視爲開
銷，並縮減其支出。創新型公司則將軟件視爲競爭優勢。
5. 在量子級別隔離架構特徵
過在架構量子級別隔離技術架構，架構師可以專注於單個量子的主要特徵，
而無須權衡競爭優先級。
8.7.3 企業爲何選擇不構建演進式架構
1. 大泥團無法演進
2. 其他架構特徵占主導地位
3. 犧牲架構
4. 計劃即將停止業務
8.8 商業案例
8.8.1 未來已來……
擁有現代軟件架構的公司可能顛覆性地
進入現有的業務領域，並快速佔領市場，因爲他們的信息技術更先進。
8.8.2 沒有後顧之憂地快速前行
如果開發人員構建允許增量變更、比舊架構更強大的架構，將會帶來
業務和工程上的雙贏
8.8.3 風險更低
8.8.4 新能力
8.9 構建演進式架構
由於架構團隊和組件使用團隊缺少連接，因此架構團隊很難設計出一個有口皆碑，受使用者歡迎的組件。
我們之前都是這麼做的，在這種架構模式中，我們有一個巨型數據庫，所有的數據都囊括其中。圍繞着這個數據庫的周圍，有一圈各種各樣的應用，它們支配着這些數據。
首當其衝的是它讓組織者知道並不是所有的東西都必須是模塊化的。與此同時，它也激發了大家開始思考，將多種功能更好的集成到一起，而不是緊耦合到一塊，比如你可以想想使用中間件，消息隊列或者其他一些更松耦合的方法。
SOA也犯了一些錯誤。最主要的一個問題是其龐大的服務。
其次，SOA傾向於提供方驅動的服務，我指的意思是，當你開始想我要寫一個用戶服務，我要給用戶提供這些信息，因爲我是這些信息的提供方。我假設我知道用戶將會如何使用這些信息。這種思路其實和設計可重用組件的架構師差不多，我們統稱爲信息提供方驅動。
SOA的另外一個問題是其充斥着大量的編配（orchestration）,注意這裏我們說的是編配而不是編排（choreography）。在管絃樂（也是orchestration這個詞）中，有一個統一的指揮，由他來指揮整個樂團，他來設置節奏，音量等各種信息。整個樂團裏的個體都無一例外的聽命於這個指揮。我們設想一下，如果某個時候同時發生兩件事，那麼可能就需要兩個指揮。總而言之，在這種模型裏面，有一個類似指揮的角色來對整個系統全盤負責。而編排卻不是這樣，在編排的時候，每個個體只需要關注自己周圍的其他成員就行，而並沒有一個統一的總指揮。當出現問題的時候，每個個體只要知道自己應該怎麼調整就行，同樣也不需要一個所謂的總指揮來指揮它進行調整。
SOA這種類似管弦樂團的組織方式，過分集中化了，從而導致其本身通常難以測試。
SOA還有一個問題是工藝受阻。SOA需要我們有這樣的供應商，能滿足業務部門的所有想法，然後業務部門只需要坐在自己的辦公室裏面做一些自定義的配置就可以了。
微服務（micro-services）
以將微服務理解成正確的SOA模式。我們的關注點還是服務，在微服務的架構裏面，服務是作爲一個基礎單元存在的。SOA本身即是面向服務的架構，所以我們這個其實也可以叫SOA2，但是我們還是用了微服務這個名字，目的就是提醒大家不要搞海量服務。這是一段James Lewis和Martin Fowler的文章中摘抄的一段關於微服務的定義：
微服務有些什麼特點呢？
第一個顯而易見的特點是，微服務中每個個體服務單元很小。
微服務的另外一個特點是，這些服務是按照業務能力構建的。
微服務中的服務個體都是可以單獨部署的。也就是說，只要沒有動接口協議，在修改某一個服務個體的時候，完全不用理會其他服務個體。
首先粒度的問題是至關重要的，當你在思考微服務的邊界問題時，這應該是使用微服務架構需要做出的一個最重要的決定。
微服務中的各個服務個體是可以獨立擴展的，也就是說如果某個服務上的需求量猛增，我們只需要擴展該服務即可，於其他服務無關。
在微服務中，我們還需要考慮服務掛掉的情況，而這些情況在傳統單塊架構裏面一般不用怎麼考慮。比如我們有一塊業務需要依賴數個獨立的微服務，那麼我們需要考慮的失敗場景就相當多了，
在微服務架構中，因爲我們有很多獨立的單元，它們需要獨自進行部署，因此我們真心離不開基礎設施的自動構建，自動化部署和持續交付這些基礎。
首先，想清楚邊界上下文。這其實是從領域驅動設計一書中拿過來的概念。所謂的邊界，指的是你可以將某些部分用一個圈圈起來，圈裏的內容代表了一定的業務面。這個所謂的邊界其實就是我們設計服務邊界時的一個重要指示。再回到我之前說的那個問題，你需要對你的系統有一個全面透徹的認知之後，才能做出這些決定。作爲劃分服務邊界的第一個提示便是：嘗試按照領域驅動設計的方式來思考服務的邊界應該在哪裏。
其次還是這一點：從業務能力的角度來思考服務的邊界。想想系統所提供的產品、服務是什麼，從這個角度想想怎麼樣纔算一個合理的服務邊界。
想想調用者需要什麼。
想想服務之間的通信模式。
想想數據結構。
想想聯動變化模式。
那麼微服務與演進式架構還有什麼聯繫呢？
主要是想用它來快速應對頻繁的需求變更，因此微服務所承載的期望便是讓我們能儘可能快的適應變化。而演進式架構中所倡導的進化性與此不謀而合。
遵從康威法則。我們需要關注怎麼組織團隊結構，以及不同的團隊結構可能影響到最終的系統形態。只有團隊對服務有很好的所有權意識，團隊做出來的微服務纔是這種松耦合的獨立服務
適當耦合。
協議。在微服務架構中，各個服務可以獨立演進。那麼必不可少的一環就是相互之間的接口協議。
不管是從代碼層面還是系統層面，關注測試始終會讓你的架構更加完善
微服務相比於傳統架構，增加了大量的運維負擔。有更多的東西需要部署，有更多的地方需要監控，出錯的地方自然也成倍增加，有更多的數據庫，對應的需要更多的備份。