一、微服務及微服務架構
微服務核心就是把傳統的單機應用，根據業務將單機應用拆分爲一個一個的服務，徹底的解耦，每一個服務都是提供特定的功能，一個服務只做一件事,類似進程，每個服務都能夠單獨部署，甚至可以擁有自己的數據庫。這樣的一個一個的小服務就是微服務。
微服務架構是一個架構風格，將一個單一應用程序開發爲一組小型服務；每個服務運行在自己的進程中；服務之間通過輕量級的通信機制(http rest api)；每個服務都能夠獨立的部署；每個服務甚至可以擁有自己的數據庫。
微服務強調的是服務的大小和對外提供的單一功能，而微服務架構是指把 一個一個的微服務組合管理起來，對外提供一套完整的服務。
1、服務架構
（1）單體架構的擴展
單體架構，當用戶增加的時候需要演變爲集羣架構，每個業務模塊都需要擴展包含前端UI，擴展的代價比較高。
（2）微服務架構的擴展
微服務架構，當用戶增加的時候可以對壓力大的模塊進行擴展，其他模塊不用擴展，這樣可以只增加較少的機器。
2. 微服務架構的優缺點
優點
①：每個服務足夠小,足夠內聚，代碼更加容易理解,專注一個業務功能點(對比傳統應用，可能改幾行代碼 需要了解整個系統)
②: 開發簡單，一個服務只幹一個事情。（加入你做支付服務，你只要瞭解支付相關代碼就可以了）
③: 微服務能夠被2-5個人的小團隊開發，提高效率
④: 按需伸縮
⑤: 前後端分離, 作爲java開發人員，我們只要關係後端接口的安全性以及性能，不要去關注頁面的人機交互(H5工程師)根據前後端接口協議，根據入參，返回json的回參
⑥:一個服務可用擁有自己的數據庫。也可以多個服務連接同一個數據庫
缺點
①:增加了運維人員的工作量，以前只要部署一個war包，現在可能需要部署成百上千
個war包 (k8s+docker+jenkis )
②: 服務之間相互調用，增加通信成本
③:數據一致性問題(分佈式事物問題)
④:系能監控等,問題定位..........................
二、註冊中心
註冊中心原理：（訂單服務 和 商品服務註冊到註冊中心，訂單服務調用商品服務）
步驟一：訂單服務和商品服務啓動的時候，都去調用註冊中心的註冊接口，向註冊表中增加記錄；
定時任務：TimeTask1 訂單服務和商品服務向註冊中心定時發送心跳，更新 last_heartTime 字段的時間；
訂單服務的 TimeTask2 定時從註冊中心拉取 商品服務 的實例IP並存儲到訂單服務的緩存中（通過Ribbon組件）；
TimeTask3 是註冊中心的定時任務：定時清理沒有心跳的實例信息，將記錄的狀態修改爲 down；
步驟二：訂單服務和商品服務在服務關閉的時候，調用註冊中心的服務註銷接口，從註冊表中刪除記錄；
說明：
註冊接口業務邏輯：insert into server_register_table(id,service_name,ip,port,status) values(?,?,?,?)
服務發現接口業務邏輯：select * from server_register_table where service_name='product-server' and status = 'up'
服務心跳接口業務邏輯：update server_register_table set last_heartTime = current_time where service_name='product-server' and ip = '192.168.159.2'
註銷接口業務邏輯：delete from server_register_table where service_name = 'order-server' and ip='192.169.158.1'
TaskTimer3的業務邏輯(假設剔除15s沒有續約的服務)：update server_register_table set status='down' where current_time-last_heartTime>15
三、spring boot、spring cloud、spring cloud netflix、spring cloud alibaba
1、spring boot、spring cloud、spring cloud netflix、spring cloud alibab的區別和聯繫
（1）spring boot：是用來快速開發微服務的web服務；
（2）spring cloud：是微服務架構的一套工具集；
（3）spring cloud netflix：國外的一個開發微服務的工具集， 是spring cloud的子項目；
（4）spring cloud alibaba：阿里開源的，符合中國企業的一套微服務架構解決方案，也是 spring cloud的子項目；
2、版本的選擇
（1）spring boot 版本選擇 （以 2.1.6.RELEASE 版本爲例）
2：表示的主版本號，表示是我們的SpringBoot第二代產品
1：表示的是次版本號，增加了一些新的功能但是主體的架構是沒有變化的，是兼容的
6：表示的是bug修復版
所以2.1.6合起來就是springboot的第二代版本的第一個小版本的 第6次bug修復版本
RELEASE:存在哪些取值了 ①:snapshot(開發版本) ②:M1...M2(里程碑版本,在正式版發佈之前 會出幾個里程碑的版本) ③:release(正式版本)
（2）spring cloud的 版本選擇
第一代版本:Angle
第二代版本:Brixton
第三代版本:Camden
第四代版本:Edgware
第五代版本:Finchley
第六代版本:GreenWich
第七代版本:Hoxton(還在醞釀中，沒正式版本)
這種發佈的版本是 以倫敦地鐵站發行地鐵的站
SNAPSHOT： 快照版本，隨時可能修改
M： MileStone，M1表示第1個里程碑版本，一般同時標註PRE，表示預覽版版。
RC 版本英文版名字叫Release Candidate（候選版本）一般標註PRE表示預覽版
SR： Service Release，SR1表示第1個正式版本，一般同時標註GA：(GenerallyAvailable),表示穩定版本
比如還有一種 RELEASE 版本（正式版本） 比如 Greenwich版本順序
Greenwich.release -----> 發現bug -----> Greenwich.SR1------> 發現bug----> Greenwich.SR2
四、微服務註冊中心
1、服務的提供者 & 服務的消費者
服務的提供者 & 服務的消費者是相對的概念，比如用戶服務是訂單服務的消費者，訂單服務是用戶服務的提供者。
但是對於 訂單服務---->庫存服務，那麼訂單服務就成爲服務消費者
2、無註冊中心的調用的缺點
（1）在服務消費方調用服務提供方的時候，請求的Ip地址和端口是硬編碼的；
（2）若此時，服務提供方的服務（訂單服務）部署的機器換了端口或者是更換了部署機器的Ip，那麼消費方服務（倉儲服務）就要修改代碼並重新發布部署；
（3）若服務提供方的服務（訂單服務）壓力過大，需要將提供服務方的服務（訂單服務）作爲集羣部署，那麼意味着訂單服務是多節點的，需要運維人員在服務消費方手動維護一份註冊表（容易出錯）。
（4）當然，有人會說可以使用 nginx 解決 （3）的問題，但是當服務出現了成百上千的時候，nginx 的配置文件就太大太複雜了；