演進式架構師
系統(tǒng)的成功靠不斷的取舍實現(xiàn)
1. 架構師的職責
1) 技術愿景梅鹦、技術領導者，帶領團隊交付客戶想要的系統(tǒng)
2) 從更高層次思考，權衡利弊塑崖，作出抉擇
2. 架構師的演化視角
1) 軟件是持續(xù)演化的文黎，不是一成不變的惹苗。
2) 對于架構師來講殿较，不要想著一開始就設計出完美產(chǎn)品，而是要設計一個合理的框架桩蓉，在這個框架下可以逐漸演化出客戶想要的系統(tǒng)淋纲。
3) 系統(tǒng)不但要滿足當前的需要，還能夠應對將來的變化
3. 微服務架構師關注點
應該關注：
1) 分區(qū)：劃分服務的邊界院究，確定服務的粒度
2) 區(qū)域間的交互：不同的服務之間是如何交互洽瞬，制定統(tǒng)一的接口，比如REST接口
3) 對整個系統(tǒng)的健康進行監(jiān)控
4) 編碼：架構師需要花時間和開發(fā)工程師在一起儡首，理想狀況下應該一起編碼
不應該關注：
1) 過多關注每個區(qū)域內(nèi)發(fā)生的事情：每個服務內(nèi)部可以允許團隊自己選擇不同的技術椘危或者數(shù)據(jù)存儲技術
4. 微服務架構的目標、原則與實踐
1) 業(yè)務部門的目標：
確保技術和業(yè)務層面能保持一致
2) 原則：
區(qū)分約束和原則：約束不能改變的蔬胯，而原則是可以改變的对供。
Heroku的12 Factors
3) 原則和實踐相結合
實踐：a. 保證原則得到實施；b. 指導如何完成任務氛濒；c.是和技術相關的产场；d.比較底層的；e. 例如：代碼規(guī)范舞竿、日志數(shù)據(jù)格式京景、http/rest作為標準集成風格，服務部署在不同的aws賬戶中等骗奖。
原則指導系統(tǒng)的演化
實踐：指導如何實現(xiàn)原則的細節(jié)
不同的實踐后可以有一個原則：.Net 團隊／Java團隊都各有自己的實踐确徙，但背后的原則是相同的。
目標 ? ? ? ? ? ? ? ? ? ? 原則 ? ? ? ? ? ? ? ?實踐
5. 微服務架構的要求
1) 監(jiān)控
a. 原則：清晰描繪出跨服務系統(tǒng)的健康狀態(tài)
b. 實踐：每個服務主動把標準化的數(shù)據(jù)推送到一個集中的位置执桌。例如：Graphite來收集指標數(shù)據(jù)鄙皇；Nagios來檢測健康狀態(tài)；輪詢系統(tǒng)來從各個節(jié)點收集數(shù)據(jù)等仰挣。
2) 接口
a. 原則：選用少數(shù)幾種明確的接口
b. 實踐：
i. 使用一種標準的接口
ii. 不僅僅是接口的技術和協(xié)議
iii. Url中使用動詞還是名詞
iv. 資源的分頁
v. Api的版本管理
3) 架構安全性
a. 原則：保證每個服務都可以應對下游服務的錯誤請求
b. 實踐：
i. 每個下游服務使用自己的連接池
ii. 每個服務使用一個斷路器
iii. 返回碼遵守一定的規(guī)則：正常且被正確處理的請求伴逸；錯誤請求；被訪問的服務宕機膘壶，無法判斷請求是否正常
4) 代碼治理
a. 原則：使用簡單的方式把事情做對
b. 實踐：
i. 范例：代碼范例
ii. 服務代碼模板：實現(xiàn)一個新服務時错蝴，所用實現(xiàn)核心屬性的那些代碼都是現(xiàn)成的，即基于模板的颓芭。
6. 技術債務及例外管理
技術債務：
無法遵守原則會導致技術債務顷锰。
架構師要理解債務的層次，對系統(tǒng)的影響畜伐，做出權衡
例外管理：
系統(tǒng)偏離了制定的原則和實踐式的處理方式馍惹。如果例外很多，要修改原則和實踐以應對真正的需求。
比如：
在大多數(shù)場景下使用MySQL做存儲万矾，如果時數(shù)據(jù)快速增長的場景悼吱，可以使用Cassandra
7. 治理：
COBIT(Control Objectives for Information and Related Technology)對治理的定義：
治理通過評估干系人的需求、當前狀況及下一步的可能性來確保企業(yè)目標的達成良狈，通過排優(yōu)先級和做決策來設定方向后添。對于已經(jīng)達成一致的方向和目標進行監(jiān)督。
治理確保構建的系統(tǒng)服務技術愿景薪丁，并在需要的時候?qū)υ妇斑M行演化遇西。
治理是個小組活動，小組由技術專家領導严嗜，并要有一線人員參與粱檀。這個小組也負責跟蹤和管理技術風險。
