2、微服務思想

2.1核心思想

相比於建造建築物，在軟件中咱們會面臨大量的需求變動，使用的工具和技術也具備多樣性。

咱們創造的東西並非在某個時間點以後就再也不變化了，甚至發佈到生產環境以後，軟件還能繼續演化。

所以，必須改變那種從一開始就要設計出完美程序的想法，相反的，更應該設計出一個合理的框架，在這個框架下能夠慢慢演化出正確的系統，而且一旦咱們學到了更多知識，應該能夠很容易的應用到系統中。

咱們不該該過多的關注每一個區域內發生的事情，而應該多關注區域之間的事情。

擔憂服務之間的交互，勝於過多關注各個服務內部發生的事情。

2.2目標、原則和實踐

基於要達到的目標去定義一些原則和實踐，對作設計來講很是有好處，不會偏離初衷。

目標

目標的層次通常都很高，一般也不會涉及技術層面，通常在公司或者部門層面指定。這些目標能夠是「提升研發效率」或者「提高代碼質量」。這些都是你的組織前進的方向，因此須要確保技術層面的選擇可以與之一致。

原則

爲了和更大的目標保持一致，咱們會制定一些具體的規則，並稱之爲原則，它不是一成不變的。

通常來說，原則最好不要超過10個，或者可以寫在一塊白板上，否則你們會很難記住。並且原則越多，他們發生重疊的衝突得可能性就越大。

實踐

經過相應的實踐來保證原則可以獲得實施，這些實踐能指導咱們如何完成任務。實踐應該鞏固原則。

2.3規約標準

在微服務能夠完成上述目標的同時，咱們還須要識別出各個服務須要遵照的通用規則。

當咱們在考慮一個更大的全景圖時，圖中應是許多系統由不少很小的可是有自治生命週期的組件構成，並且這些組件之間有着緊密的關聯。因此在優化單個服務自治性的同時，也要兼顧全局。

咱們應該清楚的定義出一個好服務應有的屬性：

Ø   監控：可以清晰地描繪出跨服務系統的健康狀態，各個服務以一樣的方式報告健康狀態與監控數據；

Ø   接口：選用少數幾種明確的接口技術有助於新消費者的集成，不只僅是技術和協議，要細化到規範（描述URL使用動詞仍是名詞，如何處理資源分頁，如何處理不一樣版本的API）；

Ø   安全性：必須保證每一個服務均可以應對下游服務的錯誤請求（使用斷路器、使用本身的鏈接池，返回碼也應該遵照必定的規則）；

2.4組織管理

在開發軟件的過程當中，除了應該多思考墨菲定律，也要思考康威定律。

就如何作事情達成共識是一個好主意。可是，確保人們按照這個共識來作事情就沒那麼容易了。某些標準或許會成爲開發人員的負擔。有效的兩種方式是：

範例：編寫文檔是有用的，可是開發人員更喜歡能夠查看和運行的代碼；

服務代碼模板：針對本身的架構裁剪出一個代碼服務模板，不但能夠提升開發速度，還能夠保證服務質量；

建立服務代碼模板不是某個中心化工具的則指，也不是架構團隊的職責。應該經過合做的方式定義出這些實踐，因此你的團隊也須要負責更新這個模板（內部開源的方式可以很好地完成這項工做）。

做爲技術領導人來講，更重要的事情是幫助你的隊友成長，並保證他們能夠積極地參與到願景的實現和調整中來，當這些人獲得足夠的鍛鍊以後，就能夠更他們更多的責任，從而幫助他們逐步達成本身的職業目標，同時經過分擔職責也能夠防止某一我的的負擔太重。

偉大的軟件來自於偉大的人。若是你只擔憂技術問題，那麼恐怕你看到的問題遠遠不及一半。

2.5小結

主要總結了在設計系統時，尤爲是使用微服務設計系統時的一些思想、作法、標準和管理，並沒有落實到具體技術上。

在微服務系統中，設計者須要作更多的決定，所以，能更好的平衡這些決定帶來的利弊是很是關鍵的。

接下來會從技術的角度來看如何設計微服務。