用戶69330831
我用了兩三年的微服務了，一般來說不到萬不得已不要過早的重構架構，凡事有利就有弊，微服務固然有很多優點，也存在很多缺點！
一開始的系統多半是集成應用，所有業務功能耦合在一個應用裡，在單臺服務器性能支撐不了的時候，採用nginx負載均衡加多臺應用服務器組成的集群來應付，但是業務代碼始終耦合在一起，某個業務功能上線帶上bug，整個系統都有風險，修復的時候需要撤下整個系統！
然後以webservice為主的SOA架構走上舞臺，通過服務化治理，將業務功能進行拆分並單獨部署，服務之間通過某種協議進行通信和數據傳輸，但是SOA架構通常比較笨重，雖然解耦了業務功能，單一服務功能的單一選擇，但是SOA的接口暴露協議太過笨重，還遵循ESB企業服務總線，開發難度不低！
SOA雖然已經實現了業務間的解耦，但是粒度較粗，所以更為細粒度的微服務框架開始逐漸流行(以springcloud和dubbo為代表)，讓服務實現組件化，圍繞著業務細領域進行服務的開發和部署，可以說微服務秉承了SOA的優良特點的同時，擁有著更多特性。
以springcloud為例，通常基於springboot進行服務開發，然後使用服務註冊與發現中心eureka，zk等實現服務之間的統一發現和調用，使用分佈式配置config將配置文件進行單獨的部署，在啟動服務的時候從配置中心獲取到配置，使用zuul實現網關的動態路由和監控，使用hystrix實現服務熔斷，防止服務雪崩帶來的影響，使用feign實現客戶端的負載均衡，可以說springcloud微服務家族提供了更為完善的組件化開發方式，為微服務的集成開發提供了極大的便利！
微服務很快的吸引了大量的公司加入，因為中大型應用在微服務的架構中有著更加靈活的開發和部署，但是微服務也有著很大的缺點，比如服務之間數據一致性難保證，通信存在隱患，大量微服務容器的管理，運維也是很大的壓力！
當然，微服務的東西涉及到的技術比較廣，實際情況也比較複雜，只有在實際中不斷碰釘子，才能對微服務更加的瞭解，如果您在微服務處理中，有實際問題，歡迎一起交流，更多的技術分享，敬請關注。。。
