照護平臺架構
通俗點講
SaaS：軟件即服務，簡單來說就是把企業想要的功能開發好成應用軟件，然後直接賣給用戶使用。通俗點講就是去飯店吃飯一樣，什麽都是店家的。
PaaS：平臺即服務，簡單來說就是雲計算平臺提供硬件、編程語言、開發庫等幫助用戶更好更快的開發軟件。通俗來說就是點外賣，使用時店家的，但是餐桌是自己的。
IaaS：基礎設施即服務，簡單來說就是雲服務商提供企業所需要的服務器、存儲、網絡給企業用。通俗來說就是買菜買面，回家自己做飯。
REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。
Web 應用程序最重要的 REST 原則是，客戶端和服務器之間的交互在請求之間是無狀態的。從客戶端到服務器的每個請求都必須包含理解請求所必需的信息。如果服務器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用服務器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。
使用SpringBoot開啟微服務之旅
微服務可以使你的代碼解耦
微服務可以使不同的團隊專註於更小範圍的工作職責、使用獨立的技術、更安全更頻繁地部署
SpringBoot支持各種REST API的實現方式
服務發現和服務調用是獨立於服務平臺的
Swagger生成穩健的API文檔和調用接口
服務治理框架（EureKa,Ribbon,Hyrstrix）
Eureka簡介
Eureka是Spring Cloud Netflix微服務套件中的一部分，可以與Springboot構建的微服務很容易的整合起來。
Eureka包含了服務器端和客戶端組件。服務器端，也被稱作是服務註冊中心，用於提供服務的註冊與發現。Eureka支持高可用的配置，當集群中有分片出現故障時，Eureka就會轉入自動保護模式，它允許分片故障期間繼續提供服務的發現和註冊，當故障分片恢復正常時，集群中其他分片會把他們的狀態再次同步回來。
Ribbon：微服務實現負載均衡
Hyrstrix ：
Hystrix說明
1.服務雪崩效應：是一種因 服務提供者 的不可用導致 服務調用者 的不可用,並將不可用 逐漸放大 的過程。
1) A為服務提供者, B為A的服務調用者, C和D是B的服務調用者. 當A的不可用,引起B的不可用,並將不可用逐漸放大C和D時, 服務雪崩就形成了
2.雪崩原因：
1) 服務提供者不可用
a.硬件故障
a1.
a2.網絡硬件故障造成的服務提供者的不可訪問
b.程序Bug
c.緩存擊穿：緩存應用重啟, 所有緩存被清空時,以及短時間內大量緩存失效時. 大量的緩存不命中, 使請求直擊後端,造成服務提供者超負荷運行,引起服務不可用
d.用戶大量請求：在秒殺和大促開始前,如果準備不充分,用戶發起大量請求造成服務提供者的不可用
2) 重試加大流量
a.用戶重試：用戶由於忍受不了界面上長時間的等待,而不斷刷新頁面甚至提交表單
b.代碼邏輯重試：服務調用端的會存在大量服務異常後的重試邏輯
3) 服務調用者不可用
a.同步等待造成的資源耗盡：使用 同步調用 時, 會產生大量的等待線程占用系統資源. 一旦線程資源被耗盡,服務調用者提供的服務也將處於不可用狀態, 造成服務雪崩效應產生
3.雪崩應對策略：
1) 流量控制
a.網關限流
因為Nginx的高性能, 目前一線互聯網公司大量采用Nginx+Lua的網關進行流量控制, 由此而來的OpenResty也越來越熱門.
b.用戶交互限流
具體措施:
a21. 采用加載動畫,提高用戶的忍耐等待時間.
a22. 提交按鈕添加強制等待時間機制.
c.關閉重試
2) 改進緩存模式
a.緩存預加載
b.同步改為異步刷新
3) 服務自動擴容
a.AWS的auto scaling
4) 服務調用者降級服務
a.資源隔離：主要是對調用服務的線程池進行隔離.
b.對依賴服務進行分類
依賴服務分為: 強依賴和若依賴. 強依賴服務不可用會導致當前業務中止,而弱依賴服務的不可用不會導致當前業務的中止.
c.不可用服務的調用快速失敗
一般通過 超時機制, 熔斷器 和熔斷後的 降級方法 來實現
4.解決方案：
1)使用Hystrix預防服務雪崩
2)Netflix的 Hystrix 是一個幫助解決分布式系統交互時超時處理和容錯的類庫, 它同樣擁有保護系統的能力
3)Hystrix的設計原則包括：資源隔離、熔斷器、命令模式
Maven
maven：項目管理工具 ， 跟ant差不多。
照護平臺架構