目前很多互聯網公司都採用微服務架構，微服務的優點和缺點被反覆說到，這裏不在重複贅述，只結合工作中的一些實踐，說說要用微服務要注意的點，厚顏寫做編程範式，其實就是一些具體實踐而已。
原則（道）
原則是比較抽象的一個概念，簡單說是一些指導意見，在不同的組之間可以共享，是爲了實現一個共同的目的，必須準守的一些規則，或者叫做規矩。
這些規則（或規矩）對我們開發過程中有一定的約束作用，不容置疑，必須遵守。如果發現有那個團隊或者個人沒有準守，一定要及時糾正，否則，原則就沒有任何存在的意義。
現在用的很廣的一個原則是Heroku的 12-Factor 原則。具體內容如下：
I. 基準代碼
一份基準代碼，多份部署
II. 依賴
顯式聲明依賴關係
III. 配置
在環境中存儲配置
IV. 後端服務
把後端服務當作附加資源
V. 構建，發佈，運行
嚴格分離構建和運行
VI. 進程
以一個或多個無狀態進程運行應用
VII. 端口綁定
通過端口綁定提供服務
VIII. 併發
通過進程模型進行擴展
IX. 易處理
快速啓動和優雅終止可最大化健壯性
X. 開發環境與線上環境等價
儘可能的保持開發，預發佈，線上環境相同
XI. 日誌
把日誌當作事件流
XII. 管理進程
後臺管理任務當作一次性進程運行
在我們團隊中有一些原則可以和大家分享：
- 不要爲了用而用，程序猿（或者叫攻城獅）是最喜歡嚐鮮的人，有了新技術出來，就想用。這無疑是優點，但是在工作中這樣，就有可能給系統帶來災難。所以如果想用某項技術，必須充分調研之後，經過一系列的驗證，才能引入。
- 戰略目標明確，業務部門願景清晰。作爲開發團隊，可能很少關心業務團隊的想法，這是很致命的。我們開發的東西，不是業務部門想要的，顧客想要一個喫飯的勺子，你給做了一個鐵鏟，鐵鏟做的再好又有什麼用。
- 服務之間調用必須使用HTTP/RESTful方案，不能引入其他方案。不是說其他方案不好，而是最好協議一致，一致的協議能夠減少系統的複雜性和溝通成本。
標準（術）
標準的定義會比原則更加具體，有點類似於道和術、戰略和戰術的關係，不同的技術棧、不同的團隊可能會制定不同的標準。
- 我們團隊都是使用的是Java技術棧，所以標準大體上採用的是《阿里巴巴Java開發手冊》，有一部分內容作了修改，這裏對孤盡表示感謝。這個手冊脫胎於《Effective Java》和《代碼簡潔之道》，其中加入了孤盡在阿里的一些實踐，所以對於Java棧的同學是比較適用的。
- 我們使用的是Spring Cloud，服務之間的調用，必須使用Feign Client形式，指定這個標準是爲了以後使用K8s時改動最小。
- 頁面與服務之間的調用，HTTP返回狀態碼都是200，在返回的數據中，定義具體的狀態碼，這個狀態碼參照HTTP狀態碼，同時定義一個子級狀態碼，用來具體定義業務情況。比如，狀態碼等於500標識服務異常，子級狀態碼等於5001，表示操作數據庫異常等。
- 監控系統、日誌系統、任務調度等，如果需要，也要指定明確是標準。比如打印日誌時，日誌開頭必須以6位數字開頭，因爲我們的日誌系統與監控系統對接，6位數字能夠定位到不同的系統、模塊、業務，直接定位問題位置。
- 不一而足（每個團隊有每個團隊具體的標準，這裏就不一一列舉了）。。。
這些標準，最好形成文檔，放在知識庫中。這樣，團隊的成員可以隨時查看，有新人加入時，也能避免老員工口口相傳，傳錯了指令。
有些架構師認爲，原則和標準就是一個東西。就我來看，這兩個粒度不同，對於大的團隊，最好分開。因爲大的團隊，技術棧更加多樣化，標準沒有辦法做到一致，但是原則可以做到不會脫離大框。對於小的團隊，因爲技術棧比較單一，有可能就是一個技術棧（就像我現在的團隊），因爲標準只有一個，就是對原則的細化，所以兩者就是一個東西。
標準的另外一個作用，就是告訴團隊成員怎麼做是對的，怎麼做是更好的方案，更加直白的表述是，按照標準進行開發，bug更少。
有了開發標準之後，就需要將標準推廣到所有人，但是每個人的理解力和執行力是有偏差的，所以需要一些手段來快速推廣。具體的方法有：DEMO（示例）、代碼模板（腳手架）。
DEMO（示例）
軟件開發是一個比較有技術壁壘的行業，一個新人（沒有經驗或者有經驗剛加入新團隊的人）想要快速瞭解老系統所使用的標準，是比較困難的，畢竟每家團隊採用的標準都不是百分之百一致。比較簡單的做法就是，提供新人DEMO示例，然後告訴他，“就照着這個做”。
對於有經驗的新人，一定是先接受，然後在瞭解清楚之後，纔會提出自己的一些看法，而不是一上來，就搬出自己以前的經驗，全盤否定團隊指定的標準。
代碼模板（腳手架）
代碼模板的作用實現一個服務的集成方案，經過有效可靠的裁剪和定製。在需要新建服務時，就使用這個方案，直接進行業務代碼開發即可，所以也被稱爲腳手架，比如SpringBoot的Starter和AutoConfiguration。
前面說過，我們團隊使用的是Java技術棧，基於SpringCloud開發，所以我們對SpringCloud進行封裝，定義了幾根通用的組件，比如定義了一個web-misc組件，引入這個組件，就能夠實現，引入實現WebMvc，並且提供了統一的獲取Metric信息的接口，統一的異常處理的ExceptionHandler等。
及時清理技術債務
雖然我們都是代碼潔癖，但是有時候迫於時間壓力、業務壓力，我們不得不揹負一些技術債務。
比如我們知道硬編碼會破壞系統靈活性，但是明天就要上線，根本沒有時間做配置型服務，所以只能硬編碼到系統中，這就是技術債務。第二天系統上線，正常運行，如果這個時候把硬編碼事情拋之腦後，這個債務就會產生利息，不知道哪天就會變成炸彈。
對於技術債務，我們團隊的做法是做一個技術債務清單，設置超時提醒功能，限期修復。這個清單是公開的，每一項都註明了，是誰，因爲什麼，於什麼時間，產生的技術債務，需要在什麼時候修復。如果是臨時特性或功能產生的債務，也需要註明特性或功能過期時間，由專人檢查債務是否已經沒有了。
個人主頁: http://www.howardliu.cn
個人博文: 微服務編程範式
CSDN主頁: http://blog.csdn.net/liuxinghao
CSDN博文: 微服務編程範式