一、應用背景
隨着計算技術的進步，內存、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