背景
去年年底的时候，静儿在团队会议中提出了自己的对整个服务将来的规划。静儿心里明白自己的架构设想是可实现的，但是远超目前的架构。被质疑无法落地。于是静儿将一些概念的东西全都抛去，直接针对具体的项目做领域拆分。项目也在一点点像静儿原来规划的演进。
静儿认为这个不做管理的一个好处：「对技术的挑战要大的多。」经常很多东西后来被证明是对的，但是当时因为没有办法说服别人走了很多弯路。在一个好的团队，很多人都有自己的想法，想说服别人很难。一个很开放的管理者也很难去在自己有一个想法，别人有一个想法的时候从自己的思路从脱离出来按照别人的方法去思考和实施。
其实团队中看似不同的想法其实仔细去想会有很多共性。需要去发掘这些共性，发现不同的想法实际上并不是完全的背离的。仔细去梳理，可能会发现最终的目的地是一样的，过程也可以是大家都满意的。
在新版架构中，静儿提出了具体模块的领域划分，得到大家的认可：这样划分确实是更合理的。静儿自己设计开发了其中几个模块之后，又提出了更大的概念：整个调度平台可以划分为调度(动态的)和资源(静态的)两个大模块。再在底层划分领域，形成4层的树形领域结构。这个思想慢慢也在得到大家的认同。最终，从设计标准上，架构是在向服务网格方向发展的。
什么是服务网格
服务网格定义
服务网格(service mesh)是面向基础设施层的，作用是让服务间（尤其是云原生应用这样复杂的服务）的通信安全、快速和可靠。
云原生定义
云原生(cloud native)是一种构建和运行应用程序的方法，意味着应用程序位于云中，而不是传统数据中心。2015年Linux基金会推出了云原生应用基金会(CNCF)，CNCF将云原生定义为使用软件堆栈进行容器化，其中应用程序的每个部分都打包在自己的容器中，动态编排，以便每个部分都被主动调度和管理，已优化资源利用率和面向微服务的应用程序，以提高应用程序的整体灵活性和可维护性。
服务网格和云原生是什么关系
结合起来是一个比较好的事件，特别是CNCF推荐的实践。但是也可以不结合独立实现。
服务网格和微服务架构是什么关系
微服务架构是一个理念，到底自己的项目是不是微服务风格的，自己只要能自圆其说就可以。服务网格是有一些基础设施组成的，更具体。
微服务更偏向于领域的拆分，而服务网格侧重于解决的模块之间的通信。
自己项目中有没有必要使用服务网格
首先服务网格起源于Linkerd，现在比较火的是Istio。它们是希望提供一个自上而上的服务网格解决方案。里面提的理念都很好，但是现实中总是会遇到各种问题。不建议对稳定性要求很高的项目接入尝试。稳定性的要务之一：「不当小白鼠。」
而对于很多大公司，事实上做着与服务网格异曲同工的事情，举个大家相对比较熟悉的东西：服务治理。静儿在《美团分布式服务通信框架及服务治理系统OCTO》里也提到OCTO正在和静儿所在的HULK团队做更深度的合作，静儿自己的观点：事实上在自下而上的打造着「服务网格」。
标准服务网格中的几个基础设施
Sidecar（挎斗）模式
Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。
举个栗子🌰：
静儿在《美团分布式服务通信框架及服务治理系统OCTO》里提到sg_agent作为独立本地进程放到客户端为客户端提供路由策略等服务，这本质上可以作为一种Sidecar模式的实现。
Data Plane（数据平面）
Data Plane原始的意思是：用来将路由器的数据包从input送到output（forwarding）。在服务网格中的作用是处理网格内服务间的通信，并完成服务发现、负载均衡、流量管理、健康检查等功能。
Control Plane（控制平面）
Control Plane原始的意思是：用于将数据包从一个路由器发到另一个路由器（Routing）。在服务网格中的作用是管理和配置Sidecar、执行侧率并收集监控等数据。
Data Plane和Control Plane都可以在服务治理当中找到对标。
总结
不要在盒子外面思考，要找到盒子 --《程序员修炼之道》
