聲明：如下文字純屬個人想法，不保證適合所有人或企業，也代表任何機構觀點！
就微服務框架而言，可以認爲出現了兩個版本：微服務1.0和微服務2.0
微服務1.0：
代表就是阿里開源的Dubbo和Povital的SpringCloud，相對SpringCloud而言，Dubbo更多的是一種服務治理框架，並不能完全覆蓋微服務的各項功能需求。而Spring Cloud一方面是針對微服務而設計，另外一方面Spring Cloud是通過集成各種組件的方式來實現微服務，因此理論上可以集成目前業內的絕大多數的微服務相關組件，從而實現微服務的全部功能。就Dubbo而言，如果一定要應用到微服務的使用場景中的話，則可以通過集成第三方應用和組件的方式來實現，跟Spring Cloud相比主要的缺陷在於集成過程中的便利性和兼容性等問題。
不論是Dubbo還是SpringCloud，都是面向Dev的，並不涉及Ops，同時對開發語言的支持有限制，如SpringCloud僅支持java語言。從一個項目生命週期來看，軟件功能開發僅是開始，後續如何運維、擴容都是問題，而無論Dubbo還是SpringCloud，在這方面並不擅長，或者說並未涉及，他們只是提供了把單體應用進行微服務拆分時，以及微服務運行時所需的各種組件以及協議框架，但是如何來控制運行中的應用、通信、安全等，需要運維自己想辦法。簡單來說，微服務1.0框架並沒有實現應用程序（業務邏輯）與控制層面的解耦。業務邏輯的實現和對業務邏輯的控制是揉在一起的。以openstack爲例，openstack雖然通過kolla-ansible也實現了微服務架構的理念，從整個集羣功能角色來看，也實現了數據面和控制面的分離，但是在微服務層面沒有實現功能與控制的分離，或者說宏觀上實現了分離，但是微觀上並沒有，沒有的結果就是，服務之間的通信仍然需要消息隊列中間件的存在，同時每個功能項目都剝離一個API子項目出來，如nova-api、cinder-api等等，因此在openstack中，應用與通信之間是沒有分離的，或者說服務之間的通信對應用程序不透明。
微服務2.0：
Docker+K8S+ServiceMesh，需要指出的是，微服務並不意味着一定要容器化，一定要通過docker才能實現，微服務的本質是對大型單體應用進行拆分，而不是容器化，docker的出現只是讓這些拆分後的微服務更好的實現了封裝隔離和部署交付。不使用容器，通過SpringCloud也可以實現微服務，只是此時的微服務以傳統進程方式部署在宿主機上，暴露在系統中。那麼K8S與微服務又是什麼關係？從功能覆蓋面上來看，K8S與SpringCloud有很多功能是重疊的，比如服務發現、配置管理、服務註冊、負載均衡等等，K8S主要實現對Docker容器的編排部署和管理配置等，簡單點說，把大型單體應用拆分、Docker封裝後，通過K8S就可以對其進行生命週期的管理了。相對於SpringCloud，K8S更側重於Ops，所以如果是考慮走DevOps路線，docker+K8S會是優先選擇。那麼ServiceMesh在微服務中又有什麼用？
其實用docker+K8S和SpringCloud都可以實現微服務，但是他們有個共同點，就是應用層面（業務邏輯層面）與控制層面沒有分離，雖然實現了微服務，但是在微服務這個實體裏面程序功能與對功能的控制是合在一起的。ServiceMesh要做的事情就是把應用層和通信層隔離，讓微服務之間的通信通過一個獨立層來實現，具體地說，就是通過Sidecar來實現，每個微服務在部署時候都對應有個Sidecar，所有Sidecar連接起來，就是服務網格。還是以openstack爲例，如果把openstack用SeviceMesh架構改寫，那就不需要存在MQ和API了，所有服務之間的通信全部交給服務網格（即Sindecar的實現，如Envoy），服務僅需訪問身邊的Sidecar即可實現與其他服務的通信，在不需要通過Pub/Sub機制在MQ中傳遞/獲取消息，這種模式最大的好處之一，就是在openstack大規模部署時候，再也不用擔心MQ隊列擁堵造成服務通信延遲甚至卡死或性能急劇下降了。
目前ServiceMesh實現最成熟的方案就是Istio,Istio有控制層面和數據層面之分，數據層面主要就是負責服務之間的通信，其實現主要是Enovy，而控制層面主要負責控制Enovy如何傳遞數據，說白了就是數據傳輸的控制大腦，打個比方，Enovy就是路上的高鐵列車，負責運輸，控制層面就是高鐵控制中心，什麼時候發車、開多少碼、什麼時候停車、停在哪、開車時允許的負載，都是控制中心說了算，這裏的控制中心，就是Istio的控制層面。