微服務在網際網路公司裡確實是非常容易擴充套件，又是技術實現較低的技術架構元素。
首先，系統要不要採用微服務，怎麼採用微服務，並不是一上來就要拍腦袋決定的。一些中小型的公司，其實是沒有必要的理由做這件事的。一個公司的技術架構和業務架構是相輔相成的。只有在業務發展到一定程度，需要靈活多變，同時又要應對系統性能調整和各種異常的時候，才會慢慢的採用分散式的服務架構。
其次，服務的拆分是為了更好的適用業務，更好的頂住大流量併發帶來的技術和挑戰。所以，這個服務怎麼個拆法，在不同的業務領域會有不同的方法和架構。隨著業務發展，哪些服務應該拆分，下沉，哪些應該組合抽象成中間層，會越來越明晰。
很多公司一上來就開始做非常細的服務拆分。基礎服務，中間層服務，出口層後臺服務。拆的太早，後面往往會不停的變動，反而會起到反效果。
最後，說下微服務拆分的基本套路，也算是後期必備的。好處我就不說了。一些基本思想套路是類似的。架構支援上，資料會多主多從，水平切分，快取多主多從，水平切片，各種中介軟體叢集，入口反向代理叢集，甚至硬體分發F5……接下來就是每個業務服務單元，組合或拆分，一層一層的分散式微服務。這裡面主要還涉及到服務的一些監控，安全，降級，回滾，版本等操作。推薦看下《大規模分散式系統架構與設計實戰》，《大型分散式網站架構設計與實踐》，還有一些講解樂視，支付寶，天貓，京東等的非同步解藕，服務拆分的部落格或這種通用書，關注下最近的資料庫中介軟體以及開源分散式資料庫pingcap等。這裡不在展開說，各個中介軟體叢集的實現和部署了，如果大家有興趣，我再更新。
基本的套路是類似的。只是業務不同，會有不一樣的難點。
當然很多接觸微服務的同學，往往會執著於術，而忽略了道。不是說術本身不重要，只是目前術的獲取還是相對容易的。不論是書籍，部落格，還是大公司公開的架構，都足以應付術上面臨的各種問題。難點往往在於能不能結合業務結構，給出最合適的業務拆分。
不管我怎麼說，相信大多數的技術同學，仍然會執著於術。
也放上github上star最多，集成了各個公司發展歷程的架構資料和架構發展圖。
https://github.com/davideuler/architecture.of.internet-product
裡面包括了一線網際網路公司的發展歷程。只是架構資料可能是幾年前的了。可以參考學習。
微服務在網際網路公司裡確實是非常容易擴充套件，又是技術實現較低的技術架構元素。
首先，系統要不要採用微服務，怎麼採用微服務，並不是一上來就要拍腦袋決定的。一些中小型的公司，其實是沒有必要的理由做這件事的。一個公司的技術架構和業務架構是相輔相成的。只有在業務發展到一定程度，需要靈活多變，同時又要應對系統性能調整和各種異常的時候，才會慢慢的採用分散式的服務架構。
其次，服務的拆分是為了更好的適用業務，更好的頂住大流量併發帶來的技術和挑戰。所以，這個服務怎麼個拆法，在不同的業務領域會有不同的方法和架構。隨著業務發展，哪些服務應該拆分，下沉，哪些應該組合抽象成中間層，會越來越明晰。
很多公司一上來就開始做非常細的服務拆分。基礎服務，中間層服務，出口層後臺服務。拆的太早，後面往往會不停的變動，反而會起到反效果。
最後，說下微服務拆分的基本套路，也算是後期必備的。好處我就不說了。一些基本思想套路是類似的。架構支援上，資料會多主多從，水平切分，快取多主多從，水平切片，各種中介軟體叢集，入口反向代理叢集，甚至硬體分發F5……接下來就是每個業務服務單元，組合或拆分，一層一層的分散式微服務。這裡面主要還涉及到服務的一些監控，安全，降級，回滾，版本等操作。推薦看下《大規模分散式系統架構與設計實戰》，《大型分散式網站架構設計與實踐》，還有一些講解樂視，支付寶，天貓，京東等的非同步解藕，服務拆分的部落格或這種通用書，關注下最近的資料庫中介軟體以及開源分散式資料庫pingcap等。這裡不在展開說，各個中介軟體叢集的實現和部署了，如果大家有興趣，我再更新。
基本的套路是類似的。只是業務不同，會有不一樣的難點。
當然很多接觸微服務的同學，往往會執著於術，而忽略了道。不是說術本身不重要，只是目前術的獲取還是相對容易的。不論是書籍，部落格，還是大公司公開的架構，都足以應付術上面臨的各種問題。難點往往在於能不能結合業務結構，給出最合適的業務拆分。
不管我怎麼說，相信大多數的技術同學，仍然會執著於術。
也放上github上star最多，集成了各個公司發展歷程的架構資料和架構發展圖。
https://github.com/davideuler/architecture.of.internet-product
裡面包括了一線網際網路公司的發展歷程。只是架構資料可能是幾年前的了。可以參考學習。