Kubernetes中文社区
- 服务接入层：企业暴露到外部访问的入口，一般通过防火墙等。
- 网关层：服务网关是介于客户端和服务端的中间层，所有的外部请求会先经过服务网关，为企业应用提供统一的访问控制入口。服务网关是微服务架构下的服务拆分，聚合，路由，认证以及流控综合体现。
- 支撑服务层：为企业应用提供运行所需的支撑环境，包括注册发现，集中配置，容错限流，认证授权，日志聚合，监测告警，消息服务等
- 业务服务层：业务服务是企业应用的核心所在，为企业领域应用的具体实现，一般进一步拆分为基础服务（基础功能）和聚合服务（综合场景）。
- 平台服务层：为企业应用提供运行所需的软件资源，包括应用服务器，应用发布管理，应用镜像包管理，服务治理。
- 基础设施层：为企业应用提供运行所需的硬件资源，包括计算资源，网络资源，存储资源，基本的安全策略控制等。
从这个典型的服务架构体系中，能够清晰的表明层级架构以及各层涵盖的职责说明。我们暂不考虑基础设施层和平台服务两层，重点关注网关服务，业务服务，支撑服务，突出其中的一些基础支撑功能组件，这也是我们本篇探讨的重点内容。如下图所示：
第四，所有的这些都是在应用部署阶段完成，在开发层面不需要花费大量的精力。
- 传统架构：传统架构下，支撑服务，业务服务基本上没有明确的边界区分，实现方式上都通过代码杂糅在一起。
- 微服务架构：微服务架构下，支撑服务，业务服务能够初步分离，但是需要保证代码框架的统一性和依赖性，跨语言受限比较严重。
- Service Mesh架构：Service Mesh架构下，支撑服务，业务服务能够彻底分离，不收语言限制，唯一需要考虑的是不同协议的支持情况。
通过支撑服务的转变形态可以看出，支撑服务与业务服务分离是必然趋势，而最终的受限取决于多元化的网络协议的处理分析能力。当然我们需要明确一个事实：就Service Mesh目前的发展趋势和定位而言，并不能够完全取代所有的支撑服务，例如事件消息，配置管理等。我们更多期望它能够帮助解决应用服务在网络层面需要面对的场景和问题。这也是它发挥价值的地方所在。
通过对网关服务，业务服务，支撑服务在不同体系架构下的转变，我们清晰的认识到Service Mesh能够帮助我们重点解决微服务体系下繁琐的“旁路支撑”服务，保证业务服务的简单有效性。通过演化分析，最终基于Service Mesh的企业应用架构如下图：
- 网关层的接入工作，无论是外部请求接入，还是内部服务请求转发，都可以基于 Service Mesh 提供的不同类型的 gateway 实现，同时还可以保证策略的统一控制和管理。省略了独立的网关管理控制台。
- 针对业务服务，增加了 Sidecar 的代理模型，用来处理所有的入站和出站流量，并且配合支撑服务的控制策略，实现业务服务的旁路控制功能。
- 统一面向网络的支撑服务，基于控制与数据分离的思想，根据业务的运行情况，提高企业应用运行过程中的动态控制能力。
- 层级转变：Service Mesh在设计思路上，把自己不再定位成企业应用组件，而是把自己下沉到基础设施层，成为基础设施的一部分，这样层级的转变就与企业业务本身划清楚界限。
- 方式转变：Service Mesh在实现思路上，高度抽象，聚焦于通信链路本身，而不是聚焦于组件功能上，从网络层入手，抓住了服务通信交互的本质。
- 控制转变：Service Mesh将控制和实现分离，提供统一，灵活的控制入口，能够快速方便的针对业务场景进行自定义处理。
最后的最后需要说明 Service Mesh 还不完善，还有很多问题需要在实际的企业应用过程中逐步去解决，让我们一起拭目以待吧。
本文由博云研究院原创发表，转载请注明出处。
