本文是一個系列文章，主要講述使用spring-cloud進行微服務開發的實戰。在開始之前，我們先說一下從傳統的單一部署架構到微服務的發展過程，以便讓童鞋們更好的理解微服務的概念與演進過程。

1.單體架構
在互聯網時代早期，彼時還沒有微服務的概念，企業開發應用，將所有功能都集中到一個應用中，典型的特征是tomcat servlet jsp mysql，然后將應用打包成一個war包發布。

2.集群架構
隨著時間的推移，用戶數量越來越多，訪問量越來越大，單體架構已經無法滿足需求，此時，企業使用多臺服務器集群部署的方式，通過橫向復制來解決該問題。

3.分布式應用（垂直架構）
隨著業務量繼續增大，集群部署帶來的性能提升越來越小，集群架構已經無法滿足需求，此時分布式應用應運而生：將單個應用拆分為幾個互不相關獨立運行的應用，但是應用之間可能會有數據冗余。比如商品應用中有用戶模塊，訂單應用中也有用戶模塊，他們的用戶數據和用戶應用中的用戶數據是相同的，導致了應用間的數據冗余。

4.微服務架構(SOA)
為了解決上面的分布式應用中數據冗余的問題，SOA架構應運而生：面向服務架構。所謂面向服務：即從服務的角度來拆分應用，比如一個完整的電商，可能會拆分為用戶服務、商品服務、訂單服務、庫存服務、物流服務等等，每個服務的業務劃分邊界清晰，和其他服務沒有重合，也就不存在數據冗余的情況，服務與服務之間采用RPC或者HTTP方式進行通信。SOA可以認為是一種設計思想，而微服務是一種將該思想落地的一種方式，比如spring cloud。具體什么是微服務？業界沒有統一的定義，一般認為微服務架構是一種將單體應用拆分為一組互相獨立運行的應用的方法，應用之間一般通過輕量級通訊機制進行通信（一般是HTTP方式）。

5.為什么需要微服務？
要回答這個問題，首先要了解單體架構的應用有什么問題。

單體應用的問題：
1.復雜性高，模塊與模塊之間的邊界劃分模糊，修改代碼困難，每一行代碼都可能以一種你意想不到的方式被其他代碼引用。
2.代碼可讀性、可維護性差。由于所有代碼都耦合到一起，模塊眾多，代碼量大，對代碼的可讀性和可維護性帶來的極大的困難。
3.技術替換成本高，假如想換其他的實現方式，或者換一種語言來實現，只能全部重來，無法局部替換。
4.部署風險高，每個小改動都會導致整個應用的重新部署，部署后的線上缺陷以及回滾操作都不可控。

針對以上缺點，即可總結我們為什么需要微服務:
1.微服務架構中的每一個應用都是獨立的應用，應用的邊界清晰，功能職責單一，不會出現應用間的模塊或者數據冗余。
2.由于每個應用的職責單一，因此代碼量相對較小，代碼的可讀性以及可維護性都會很好。
3.技術替換成本低，比如我的訂單服務可以使用JAVA應用，我的庫存服務可以是Python應用，而我的物流服務可能是Nodejs應用，應用間不需要保持開發語言一致，可靈活選型。
4.部署風險低，某一個應用掛掉不會導致整個應用掛掉(當然要求服務提供方和消費方都做好服務降級和熔斷)，一個應用的部署也不會影響其他應用，并且這種方式能滿足現代互聯網快速迭代的需求。

當然，微服務也不是沒有缺點：
1.首先微服務的調用鏈路長，因此針對這種很長的鏈路調用排查線上問題就變得尤為困難，此時，對微服務中的每個應用的監控就顯得尤為重要。
2.微服務眾多，服務間的調用關系--即服務治理成本較高。
3.微服務的技術成本更高（分布式緩存，分布式事務，分布式一致性等問題）。

了解了微服務的一些概念，就讓我們一起開始微服務的實戰吧！下一篇，敬請期待！

本文由博客一文多發平臺 OpenWrite 發布！ 創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的spring cloud eureka 服务之间调用_Spring-cloud微服务实战【一】：微服务的概念与演进过程...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。