一、應用背景 隨著計算技術的進步，記憶體、CPU、磁碟等資源不再是稀缺的，電腦作為應用程式的載體從單伺服器轉變為多伺服器，集中計算演化為分散式計算。原有的“巨石”應用難以適應業務的發展速度，可擴展、自適應的能力不足，程式員面對著數以萬計的源代碼文件抓耳撓腮（O M G!），越來越多的工程師渴望小而美 ...
一、應用背景
隨著計算技術的進步，記憶體、CPU、磁碟等資源不再是稀缺的，電腦作為應用程式的載體從單伺服器轉變為多伺服器，集中計算演化為分散式計算。原有的“巨石”應用難以適應業務的發展速度，可擴展、自適應的能力不足，程式員面對著數以萬計的源代碼文件抓耳撓腮（O M G!），越來越多的工程師渴望小而美、易於擴展的架構體系，微服務應運而生。自2005年首次由Peter Rodgers提出微服務概念以來，風靡一時，隨著近些年的發展，已經逐步被千萬企業所採用，多數為互聯網企業。我於工作半年之後有幸參與到後端微服務架構遷移的產品設計和開發中，有些體會，與大家分享。
二、設計原則
- SRP（Single Responseble Principle）即單一職責原則，每一個服務提供者僅暴露自己職責範圍內的介面，操作職責範圍內的DB，不繼承其他服務提供者的協議。簡單點說，該你乾的才去乾，不該乾的調用其他人的服務來乾。
- RESTful，作為Web Service的替代者，其面向資源的特性註定是為微服務而生的，介面設計符合REST設計原則將使服務易於理解和接受。需要註意的是，靈活的使用，而不是生硬的照搬REST設計，如保持請求風格一致，GET/POST，少用DELETE/PUT（仁者見仁，智者見智）；保證同類資源首碼的一致性等。REST和RPC的優劣如表2-1。說一下可擴展性吧，RPC多以client擁有server的interface來實現通信，當介面變動後，client必須馬上升級，而REST的介面協議可以不強制升級。
響應時間
用戶友好程度
可擴展性
REST
***
*****
*****
RPC
*****
**
****
- 協議，也就是實體或者Bean了，作為各個服務組件共有的內容，是組件之間調用的橋梁。服務組件之間的調用通過協議進行調用，協議儘量不去彼此繼承。如果說微服務是個分散式的世界，那麼協議就是這個世界的法律文書（感覺很嚴肅的樣子）。
三、架構圖
關鍵點：
1.服務註冊中心，zookeeper集群作為分散式調度中心，各個服務註冊在zookeeper之上，註冊內容包括服務的請求url，請求ip地址和埠，服務組件名稱，註冊時間等；
2.Gateway，服務網關作為系統的入口，具有服務轉發、授權驗證、負載均衡等作用，使用高併發框架netty實現高速轉發等；
3.訪問控制服務，用戶首先需要獲得系統授權才可以訪問業務服務，授權通過token來實現；
4.業務服務1~N，是系統內具體業務組件的劃分；
5.用戶服務，實現用戶信息的註冊、修改、共用等；
6.配置中心，整個系統的配置均位於配置中心，組件通過訪問配置中心獲取配置參數；
7.監控系統，檢測ECS、RDS、zookeeper集群等的各項狀態；
8.Kafka消息隊列系統，支撐其他系統。
後續會對各個子系統和子系統用到的技術跟大家簡要分享。晚安。
By Will
