Spring-cloud微服務實戰【一】：微服務的概念與演進過程

本文是一個系列文章，主要講述使用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 發佈！