"
兩年前，第一次真正接觸微服務的概念，但也只是簡單地進行了使用，當時技術棧主要是 Spring Boot,那時 Spring Cloud 也比較流行，但是由於各種原因，並沒有轉向這套（甚至用 zookeeper 實現了簡單的服務發現），理論上來說，用了 Spring Boot 再轉向 Spring Cloud 應該是很正常的事情。當時也認為 Spring Cloud 各種理念很高級，實現上也不錯，也有 Netflix 等之類的大公司背書，而且和 Spring 天然集成的，使用起來還是比較方便。當時可能覺得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比簡直差了一個檔次，可能大家都認為 Spring Cloud 是未來。
從第一家公司離職後，去了另外一家公司，發現一個很奇怪的特點，這家公司的技術比較保守，基本還是十年前或者五六年前的技術架構。記得之前看過一本書上說過，技術不與時俱進，那就相當於自取滅亡，特別是技術驅動型公司，如果一直停滯不前，那就相當於你拿幾十年前的武器和別人戰鬥，那結果自然是必然的。為什麼技術要與時俱進，不是因為有了新技術就要去使用它，而是因為新技術往往可以提高業務的運轉效率，同時也可以降低成本。不過在這個公司待了兩個月，還是覺得有可取的地方，第一點是對代碼質量的追求，由於業務的體量和特殊性（大概是億級），所以對代碼有較高的要求；第二點是對微服務整體架構的深入，雖然這個系統沒有上 Spring Cloud ,甚至 Spring Boot 都沒有，還是很老的一個架構，但其中微服務的思想已經有了，比如服務的拆分，服務的水平擴展，基於 Dubbo 的一些服務發現和治理，整體來說已經算是不錯了，但是也總在思考，感覺還是少了什麼東西。
"
兩年前，第一次真正接觸微服務的概念，但也只是簡單地進行了使用，當時技術棧主要是 Spring Boot,那時 Spring Cloud 也比較流行，但是由於各種原因，並沒有轉向這套（甚至用 zookeeper 實現了簡單的服務發現），理論上來說，用了 Spring Boot 再轉向 Spring Cloud 應該是很正常的事情。當時也認為 Spring Cloud 各種理念很高級，實現上也不錯，也有 Netflix 等之類的大公司背書，而且和 Spring 天然集成的，使用起來還是比較方便。當時可能覺得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比簡直差了一個檔次，可能大家都認為 Spring Cloud 是未來。
從第一家公司離職後，去了另外一家公司，發現一個很奇怪的特點，這家公司的技術比較保守，基本還是十年前或者五六年前的技術架構。記得之前看過一本書上說過，技術不與時俱進，那就相當於自取滅亡，特別是技術驅動型公司，如果一直停滯不前，那就相當於你拿幾十年前的武器和別人戰鬥，那結果自然是必然的。為什麼技術要與時俱進，不是因為有了新技術就要去使用它，而是因為新技術往往可以提高業務的運轉效率，同時也可以降低成本。不過在這個公司待了兩個月，還是覺得有可取的地方，第一點是對代碼質量的追求，由於業務的體量和特殊性（大概是億級），所以對代碼有較高的要求；第二點是對微服務整體架構的深入，雖然這個系統沒有上 Spring Cloud ,甚至 Spring Boot 都沒有，還是很老的一個架構，但其中微服務的思想已經有了，比如服務的拆分，服務的水平擴展，基於 Dubbo 的一些服務發現和治理，整體來說已經算是不錯了，但是也總在思考，感覺還是少了什麼東西。
容器化和 CI/CD
後來又到了一家比較年輕活躍的公司，接觸到 Docker 的大規模使用以及 CI/CD，也是在這裡，形成了整個對微服務完整生命週期的理解。 Docker 其實流行也很久了， 但是真正線上使用的並沒有那麼多，最近隨著 Kubernetes（ k8s ） 的流行，更多公司也開始關注起來。
首先為什麼服務要容器化，第一點是不再依賴於運行環境，只要有 Docker 就可以跑起來，無論你是什麼發行版的 Linux 系統，還是 Windows，Mac。這有點像 JVM，屏蔽底層的細節，一次編寫，到處運行，用在容器上就是一次構建，到處運行。第二點是容器化可以更好的進行持續集成，由於第一點的緣故，部署一個服務容器將非常快捷，這更加適合目前 devops 的理念。
持續集成(Continuous Integration)簡稱 CI ,持續部署（Continuous Deployment)簡稱 CD,如果微服務不把 CI/CD 放在首位，那必然整個流程就是不流暢的。有些公司還是手動本地構建包，然後 上傳 到服務器上跑起來，進行這樣的人肉運維，人肉上線，要麼考慮一下，是不是整個 CI/CD 有問題，或者根本就沒有 CI/CD 。其次 CI/CD 流程要做到每次構建自動跑單元測試，集成測試，以及 API 測試，UI 測試等等，這些流程也沒有自動化的話，也談不上完整的 CI/CD。如果沒有經過這些流程把包直接上傳到服務器，不出問題，那應該要燒柱香，拜拜佛。
雲原生應用和服務網格
雲原生應用遵循 Twelve-Factor ，雲原生應用是為了解決傳統應用發佈升級流程緩慢、架構複雜，可維護性差而提出的的一個思想集合，集中了 微服務，devops，雲等多種思想。
雲原生應用應用可以跑在任意一家雲服務商上，也可以實現多家服務商同時使用，同時也支持公有云和私有云的混合部署，這只是它的一個特點，更多的特點還是集中在解決傳統應用面臨的問題，如灰度發佈，不停機發布，A/B Test, 快速回滾，服務治理等。
"
兩年前，第一次真正接觸微服務的概念，但也只是簡單地進行了使用，當時技術棧主要是 Spring Boot,那時 Spring Cloud 也比較流行，但是由於各種原因，並沒有轉向這套（甚至用 zookeeper 實現了簡單的服務發現），理論上來說，用了 Spring Boot 再轉向 Spring Cloud 應該是很正常的事情。當時也認為 Spring Cloud 各種理念很高級，實現上也不錯，也有 Netflix 等之類的大公司背書，而且和 Spring 天然集成的，使用起來還是比較方便。當時可能覺得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比簡直差了一個檔次，可能大家都認為 Spring Cloud 是未來。
從第一家公司離職後，去了另外一家公司，發現一個很奇怪的特點，這家公司的技術比較保守，基本還是十年前或者五六年前的技術架構。記得之前看過一本書上說過，技術不與時俱進，那就相當於自取滅亡，特別是技術驅動型公司，如果一直停滯不前，那就相當於你拿幾十年前的武器和別人戰鬥，那結果自然是必然的。為什麼技術要與時俱進，不是因為有了新技術就要去使用它，而是因為新技術往往可以提高業務的運轉效率，同時也可以降低成本。不過在這個公司待了兩個月，還是覺得有可取的地方，第一點是對代碼質量的追求，由於業務的體量和特殊性（大概是億級），所以對代碼有較高的要求；第二點是對微服務整體架構的深入，雖然這個系統沒有上 Spring Cloud ,甚至 Spring Boot 都沒有，還是很老的一個架構，但其中微服務的思想已經有了，比如服務的拆分，服務的水平擴展，基於 Dubbo 的一些服務發現和治理，整體來說已經算是不錯了，但是也總在思考，感覺還是少了什麼東西。
容器化和 CI/CD
後來又到了一家比較年輕活躍的公司，接觸到 Docker 的大規模使用以及 CI/CD，也是在這裡，形成了整個對微服務完整生命週期的理解。 Docker 其實流行也很久了， 但是真正線上使用的並沒有那麼多，最近隨著 Kubernetes（ k8s ） 的流行，更多公司也開始關注起來。
首先為什麼服務要容器化，第一點是不再依賴於運行環境，只要有 Docker 就可以跑起來，無論你是什麼發行版的 Linux 系統，還是 Windows，Mac。這有點像 JVM，屏蔽底層的細節，一次編寫，到處運行，用在容器上就是一次構建，到處運行。第二點是容器化可以更好的進行持續集成，由於第一點的緣故，部署一個服務容器將非常快捷，這更加適合目前 devops 的理念。
持續集成(Continuous Integration)簡稱 CI ,持續部署（Continuous Deployment)簡稱 CD,如果微服務不把 CI/CD 放在首位，那必然整個流程就是不流暢的。有些公司還是手動本地構建包，然後 上傳 到服務器上跑起來，進行這樣的人肉運維，人肉上線，要麼考慮一下，是不是整個 CI/CD 有問題，或者根本就沒有 CI/CD 。其次 CI/CD 流程要做到每次構建自動跑單元測試，集成測試，以及 API 測試，UI 測試等等，這些流程也沒有自動化的話，也談不上完整的 CI/CD。如果沒有經過這些流程把包直接上傳到服務器，不出問題，那應該要燒柱香，拜拜佛。
雲原生應用和服務網格
雲原生應用遵循 Twelve-Factor ，雲原生應用是為了解決傳統應用發佈升級流程緩慢、架構複雜，可維護性差而提出的的一個思想集合，集中了 微服務，devops，雲等多種思想。
雲原生應用應用可以跑在任意一家雲服務商上，也可以實現多家服務商同時使用，同時也支持公有云和私有云的混合部署，這只是它的一個特點，更多的特點還是集中在解決傳統應用面臨的問題，如灰度發佈，不停機發布，A/B Test, 快速回滾，服務治理等。
服務網格（Service Mesh）是一個比較新的概念，但是核心思想並不新。Spring Cloud 以框架的形式侵入到程序中來解決微服務的各種問題，理論上來說，應該是效率最高，最靈活的一種做法。但是侵入性太強，而且只能 Spring 這套，異構語言的系統玩不轉。Service Mesh 從另外一個角度來解決這個問題，也就是 sidecar 和 proxy，這樣雖然性能上有些損失，但是擴展性卻是比較靈活的，將這些基礎能力（服務發現，服務治理，熔斷限流，監控等）下放到基礎設施中，做到對應用程序透明，是一個不錯的進步。寫業務邏輯不需要再去和這些東西糾結，代碼邏輯也變得十分明朗。同時這樣也解決了異構語言系統的問題，無論什麼語言，都是可以完美的工作在一起，簡直是一個完美世界。但是但是但是 Service Mesh 由於還比較新，目前還不能進行生產環境使用，就拿目前最流行的 Istio 來說，目前只發布了 0.8 版本，還不能實際使用，估計 1.0 也不行，可能得 1.2 才推薦生產，所以現在就面臨一個困境，Service Mesh 是一個好東西，但是我們卻用不了，嗚呼哀哉。
Spring Cloud 和 Service Mesh
首先兩者解決問題的方式不一樣，Spring Cloud 是直接的方式，Service Mesh 是委婉的方式，這可能會造就兩者之後的命運。如果目前已經上了 Spring Cloud 或者其他的，系統已經具有基礎的服務治理能力，先不要考慮 Service Mesh ，要先去考慮容器化和 CI/CD ；如果沒有太多的歷史負擔，則是可以考慮。
總結
技術發展太快，不能停滯不前，也不能盲目追風。當年的 SSH 也只剩下了 Spring，可是有人說 Spring 只能一個季節用，但是 Service Mesh 整年都可以用，好像很有道理。最後，路漫漫而修遠兮，吾將上下而求索。