從web層架構的演進了解微服務的概念，進而對微服務的組件有一定的瞭解；
從而知道爲什麼需要這些組件，以及這些組件設計的初衷，瞭解組件的責任和邊界
單體架構
最早的時候，帶寬所限，一個tomcat就可以搞定一個網站或者項目；MVC架構非常流行
即使在現在一些簡單的網站和項目也可以使用nginx + tomcat；因爲這樣開發和維護成本比較低；
單體架構--面臨的挑戰
代碼不斷膨脹、功能越來越複雜、代碼修改牽一髮而動全身
訪問量增加、軟件和硬件都面臨挑戰、雪崩效應
重複代碼增多，重複造輪子、測試變的複雜
- 複雜應用的開發維護成本變高、部署效率變低
集中式架構SOA
SOA架構一度也非常流行，能解決我們在單體架構中存在的問題。可以看到企業總線類似於服務網關的作用。
特點：
1、基於SOA的架構思想將重複公用的功能抽取爲組件，以服務的方式給各系統提供服務。
2、各各項目（系統）與服務之間採用webservice、rpc等方式進行通信。
3、ESB企業服務總線作爲項目與服務之間通信的橋樑。
優點：
1、將重複的功能抽取爲服務，提高開發效率，提高系統的可重用性、可維護性。
2、可以針對不同服務的特點制定集羣及優化方案。
3、採用ESB減少系統中的接口耦合。
缺點：
1、系統與服務的界限模糊，不利於開發及維護。
2、雖然使用了ESB，但是服務的接口協議不固定，種類繁多，不利於系統維護。
3、抽取的服務的粒度過大，系統與服務之間耦合性高
集中式架構SOA-面臨的挑戰
SOA架構解決了應用服務化的問題、隨着服務化的越來越深入、服務規模越來越大、服務治理面臨的挑戰也越來越多
- 服務框架如何支持線性擴展
- 分佈式框架下的服務調用性能
- 如何查看日誌，快速定位和解決故障
- 服務限流、重試、超時控制、服務失敗策略
- 如何實現分佈式服務監控
微服務架構
微服務架構的特點
微服務架構實現—阿里Dubbo
註冊中心（registry）：生產者在此註冊併發布內容，消費者在此訂閱並接收發布的內容。
消費者（consumer）：客戶端，從註冊中心獲取到方法，可以調用生產者中的方法。
生產者（provider）：服務端，生產內容，生產前需要依賴容器（先啓動容器）。
容器（container）：生產者在啓動執行的時候，必須依賴容器才能正常啓動（默認依賴的是spring容器）
監控中心（monitor）：是dubbo提供的一個jar工程。主要功能是監控服務端和消費端的使用數據。
如：服務端是什麼，有多少接口，多少方法，調用次數，壓力信息等，客戶端有多少，調用過哪些服務端，調用了多少次等。
微服務架構實現—SpringCloud
基本步驟
1、啓動服務將服務註冊到註冊中心
2、啓動服務網關注冊到註冊中心
3、服務之間的調用使用一般用feign
4、外部的流量通過服務網關負載均衡
還有淘寶的HSF和亞馬遜的Coral Service、華爲在電信行業的DSF等等
微服務功能特性
單一職責，這樣能聚焦一個指定的業務功能或業務需求。
開發簡單、開發效率提高，一個服務可能就是專一的只幹一件事。
微服務能夠被小團隊單獨開發，利於敏捷交付
一個服務就是一個獨立的實體
微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的
微服務允許你利用融合最新技術和不同的言語(要考慮維護和規範)
微服務化的挑戰----管理複雜度
康威定律
運維以及監控； 服務升級、版本控制；
超大型分佈式系統需要考慮性能問題和更復雜的存儲、監控和運維等
個人寄語
技術是爲了解決問題而存在的。
架構不是一成不變的，不是說定義了單體架構,SOA架構，就一直是這樣；
架構是爲了解決問題而慢慢演變的一個過程。其實還有RPC框架；有環境的因素和實際需求共同推動。
架構是一個逐步演變的過程，soa架構也可能發展出註冊中心；
就比如esb企業總線和服務網關的概念去趨同的；
比如我2014-2016在項目中的架構使用MQ、可以算是僞分佈式架構。
但是從整體上它並不是微服務架構，從架構層面上它不滿足當前互聯網項目發展的需要；
從個體層面上。esb畢竟不是爲服務網關設計出來的，
他有他的歷史任務，所以已當前的眼光來看，它是落後的；以當時的眼光來看來看他是一個合適
的解決方案，是滿足當時所需的是優秀的
所以重申一下個人觀點，技術是爲了解決問題而存在的，我們不能說什麼技術流行就用什麼技術；
我們應該看來這個技術解決了什麼問題，然後看看它是否能解決我們的問題；