第二章 演化式架構師
不準確的比較
架構師的一個重要職責：確保團隊有共同的技術願景，以幫助我們向客戶交付他們想要的系統。
**軟件架構師和建築師是天壤之別的！不要用建築師的視角來看待軟件開發。**建築行業存在種種精確的約束，成果是一個“死”東西；而軟件開發創造的東西從設計上來說就是要足夠靈活，有很好的適應性，並且能根據用戶的需求進行演化。
架構師的演化視角
架構師必須改變那種從一開始就要設計出完美產品的想法，相反我們應該設計出一個合理的框架，在這個框架下可以慢慢演化出正確的系統，並且一旦我們學到了更多的知識，應該可以很容易地應用到系統中。
架構師應該專注在大方向上，只在很有限地情況下參與到非常具體地細節實現中來。需要保證系統不但能夠滿足當前的需求，還能夠應對將來的變化。
分區
架構師不應過多關注每個區域內發生的事，而應該多關注區域之間的事。
架構師需要花時間和團隊在一起工作，應該和團隊真正坐在一起。
一個原則性的方法
戰略目標
通常我們不需要定義戰略目標，這些戰略目標的層次一般都很高，而且一般不會涉及技術這個層面。
原則
爲了符合戰略目標，我們會制定一些具體的規則，稱之爲原則，它不是一成不變的。
例子：
戰略目標：在其它國家快速增長業務。
原則：整個系統必須能夠方便地部署到相應的國家。
原則最好不要超過10個。
Heroku的12 Factors
實踐
通過相應的實踐來保證原則能夠得到實施，這些實踐能夠指導我們如何完成任務。通常這些實踐是技術相關的，而且是比較底層的。比如代碼規範、日誌數據集中捕獲等等。
真實例子
要求的標準
系統應該由很多小的但有自治生命週期的組件構成，而且這些組件之間有着緊密的關聯。所以在優化單個服務自治性的同時，也要兼顧全局。一種能幫助我們實現平衡的方法就是，清除地定義出一個好服務應有的屬性。
監控
建議確保所有的服務使用同樣的方式報告健康狀態及其與監控相關的數據，保持標準化。
接口
選用少數幾種明確的接口技術有助於新消費者的集成。
架構安全性
必須保證每個服務都可以應對下游服務的錯誤請求。
代碼治理
範例
編寫文檔是很有用的，但開發人員更喜歡可以查看和運行的代碼。
理想情況下，提供的優秀範例應該來自真實項目，而不是一個專門實現的完美例子。
裁剪服務代碼模板
如何能夠讓所有的開發人員很容易地遵守大部分的指導原則？
一種可能的方式：當開發人員想要實現一個新服務時，所有實現核心屬性的那些代碼都應該是現成的，針對自己的開發實踐裁剪出一個服務代碼模板。
應該可以選擇是否使用服務代碼模板，但是如果強制團隊使用它，一定要確保是簡化工作，而不是使其複雜化。
小結
一個演進式架構師應該承擔的職責：
- 願景：確保在系統級有一個經過充分溝通的技術願景，這個願景應該可以幫助你滿足客戶和組織的需求。
- 同理心：理解所做的決定對客戶和同事帶來的影響。
- 合作
- 適應性：確保在你的客戶和組織需要的時候調整技術願景。
- 自治性：在標準化和團隊自治之間尋找一個正確的平衡點。
- 治理：確保系統按照技術願景的要求實現。