服务网格通常被视作开发服务的灵丹妙药，但实际上它仅针对特定的操作、安全性和流量策略，而不是所有领域。
随着企业从整体式服务转移到微服务和云原生应用程序，确保项目安全且易于实施至关重要，同时也希望能为开发人员腾出时间来进行更重要的工作。服务网格使得无需在微服务内部重新实现基础架构逻辑（例如，路由，日志记录等），从而使其真正地灵活地进行更改。
以为服务网格可以解决您所有基础架构问题？在您进行投资之前，我们建议您深入研究该技术的真实含义，这能帮助您确定服务网格是否适合您的开发周期，或者是否应该继续使用。
您无需更改微服务中的任何内容即可实现服务网格。虽然服务网格允许企业在不重写整个代码的情况下用基础结构层改造其应用程序，但您仍需要进行一些更改，特别是如果您在构建应用程序时并没有考虑到云原生设计方面的考虑。
服务网格不会神奇地使应用程序成为云原生，它仅是支持。基础架构来帮助管理微服务，而不会解决不良的微服务拓扑。如果域边界定义不正确，或者服务过于健谈，有状态或不符合12个因素，那么最终将遇到比服务网格所能解决的问题更多的问题。
开发人员仍然有责任确保遵循现代云原生技术，API管理和DevOps CI / CD最佳实践，首先使用正确的开发原则来构建微服务。抵制重新构建商品基础架构组件（记录和监视）并利用商业或商品OSS项目的冲动，而不是让每个服务团队以自治的名义从头开始构建它。
总体而言，服务网格就像在汽车中拥有最好的仪表板和控件（例如具有“运动”模式）一样。但是，如果未为其本身构建引擎（即，它正在管理的微服务），则适合利用服务网格。为了获得最佳结果，微服务设计需要正确完成，这可能意味着您需要修改已经存在的代码。
事实上，服务网格无法替代您的API管理需求。服务网格以及诸如Kubernetes之类的编排技术都可以替代某些API管理功能，但并不是所有API管理需求。
API网关是API管理和服务网格之间重叠的主要领域，它引入了入口网关的概念。API网关和服务网格均控制安全性（访问控制和身份验证），流量管理（速率限制和限制）以及路由到API。
这种重叠是许多开发人员都在努力的问题。甚至Google都必须努力解决其Apigee API管理和Istio服务网格之间的问题。
将运行时委托给入口网关，但要通过Istio Mixer适配器将所有策略和密钥管理路由回Apigee。随着时间的推移，随着这些技术的不断发展，期望更紧密的集成和更多的重叠。
服务网格实现方面缺乏标准化，尽管一些标准化工作取得进展，但一些供应商创建了自己的网格和自以为是的发行版。例如，Microsoft和HashiCorp正在为该行业开发服务网格接口。
使用服务网格，您还冒着云供应商将您锁定在其服务网格中的风险。这与服务网格的最初概念背道而驰，服务网格最初的概念是它可以与多云一起运行，但是希望标准化将使服务网格能够真正支持多云环境。
服务网格需要深入了解底层技术才能实现。尽管服务网格最终将使微服务实现变得轻而易举，但仍然需要对基础技术（如Kubernetes，Docker，Istio等）有深入的了解。
对于许多公司而言，很难找到并培养合适的技能。没有正确的知识和专业知识，最终将导致服务网格实施不佳。服务网格仍然是一项新兴技术，它正在不断发展和快速发展。作为示例，上述混合器适配器已被弃用。
从长远来看，这种“进行中的工作”有可能减慢您的实施速度，特别是当开发人员在努力提供业务价值的同时，难以跟上服务网格所基于的所有技术的最新发展时。
总体而言，服务网格就是要缩短实现价值的时间和简化开发的过程，就像中间件以前所做的那样，但是如果不了解它就跳入技术，弊大于利。
比实施最新技术更重要的是，要对微服务，小型服务以及仅通过立面的服务接口公开的主要功能做出务实的决策。不要试图煮沸海洋。
在许多情况下，企业应该真正关注的是微服务的API管理和有效的API策略。