William Morgan https://thenewstack.io/author/william-morgan/
Service Mesh 是一个相当新的概念, 讲它的 "历史" 似乎有些勉强. 就目前而言, Service Mesh 已经在部分企业生产环境中运行了超过 18 个月, 它的源头可以追溯到 2010 年前后互联网公司面对大规模业务的开发.
那么 Service Mesh 为什么会突然变成一个热门话题的?
Service Mesh 是一个软件基础设施层, 用于控制和监视微服务应用的内部, 服务到服务的通信, 通常的形式是部署在应用旁网络代理的 "数据平面(data plane)", 或者是与浙西诶代理交互的 "控制平面(control plane)". 在 Service Mesh 模式下, 开发者对服务网格无感知, 而运维人员获得了一套新工具, 协助确保服务的可靠性, 安全性和可见性.
它通常采用部署在应用程序代码旁边的网络代理的 "数据平面" 和用于与这些代理交互的 "控制平面" 的形式. 在这个模型中, 开发人员 ("服务所有者") 不知道服务网格的存在, 而操作员 ("平台工程师") 获得了一套新的工具, 以确保可靠性, 安全性和可见性.
对于很多公司来说, Docker 和 Kubernetes 已经 "解决了部署"(至少一开始是这样的), 但还没有解决运行时的问题, 这正是 Service Mesh 的用武之地.
"解决了部署" 是什么意思? 使用 Docker 和 Kubernetes 等工具可以显著降低部署时的操作负担. 有了这些工具, 部署 100 个应用程序或服务的工作量不再是部署一个应用程序的 100 倍. 这是向前迈出的一大步, 对许多公司来说, 这将显著降低采用微服务的成本. 这不仅因为 Docker 和 Kubernetes 在所有合适的级别上提供了强大的抽象, 而且因为它们标准化了整个组织的打包和部署模式.
但是一旦应用程序开始运行, 又是怎样的情形? 毕竟, 部署不是生产的最后一步 -- 这个应用程序仍然需要运行, 需要交付, 需要产生价值. 因此, 问题就变成了: 我们是否可以用 Docker 和 Kubernetes 标准化部署时间操作 (deploy-time ops) 的相同方式来标准化应用程序的运行时操作?
要回答这个问题, 不妨求教 Service Mesh.Service Mesh 的核心是提供统一的, 全局的方法来控制和测量应用程序或服务之间的所有请求流量(用数据中心的话说, 就是 "east-west" 流量). 对于采用了微服务的公司来说, 这种请求流量在运行时行为中扮演着关键角色. 因为服务通过响应传入请求和发出传出请求来工作, 所以请求流成为应用程序在运行时行为的关键决定因素. 因此, 标准化流量管理成为标准化应用程序运行时的工具.
通过提供 api 来分析和操作此流量, Service Mesh 为跨组织的运行时操作提供了标准化的机制 -- 包括确保可靠性, 安全性和可见性的方法. 与任何好的基础架构层一样, Service Mesh 采用的是独立于服务的构建方式.
Service Mesh 如何形成
那么, Service Mesh 是从哪里来的呢? 通过做一些 "软件考古学", 我们发现服务网格提供的核心功能 -- 诸如 request-level 的负载均衡, 断路器, 重试, 检测 -- 并不是基本的新特性. 相反, Service Mesh 是功能的重新打包 --a shift in where,not what.
Service Mesh 起源于 2010 年左右应用架构的三层模型 -- 一种简单的体系结构, 一度为 web 上的绝大多数应用提供 "动力". 在这个模型中, 应用流量首先由 "web 层" 来处理, 后者又会与 "应用层" 进行对话, 之后又会与 "数据库层" 对话. web 层中的 web 服务器被设计成能够非常快速地处理大量传入的请求, 并将它们小心地交给相对较慢的应用服务器(Apache,NGINX 和其他流行的 web 服务器都有非常复杂的逻辑来处理这种情况). 同样, 应用层使用数据库库与 back stores 进行通信. 这些库通常以一种针对这个用例进行优化的方式处理缓存, 负载均衡, 路由, 流控制等.
So far so good, 但是这个模型面对大规模业务时开始显露出疲态 -- 尤其是在应用层, 随着时间的推移它会变得非常大. 早期的网络规模公司 -- 谷歌, Facebook,Netflix,Twitter-- 学会了把这块巨石分解成许多独立运行的碎片, 催生了微服务的兴起. 在引入微服务的那一刻, east-west traffic 随之引入. 在这个世界上, 通信不再是专门的, 而是在每个服务之间. 当它出错时, 网站就会崩溃.
这些公司都以类似的方式进行应对 -- 他们编写了 "fat client" 库来处理请求流量. 这些库 -- 谷歌的 Stubby,Netflix 的 HYstrix,Twitter 的 Finagle-- 提供了跨所有服务的统一的运行时操作方式. 开发者或服务所有者将使用这些库向其他服务发出请求, 库将在后台执行负载均衡, 路由, 断路等等. 通过为应用中的每个服务提供统一的行为, 可见性和控制点, 这些库表面上形成了第一个 Service Mesh.
代理崛起
当我们回到当下以云为本的世界, 这些库仍然存在. 但是, 由于进程外代理提供的操作便利, 库的吸引力正在降低 -- 尤其是在与容器和编排的出现所带来的部署复杂性显著降低的情况下.
代理绕过了库的许多缺点. 例如, 当一个库发生更改时, 这些更改必须在每个服务中部署, 这个过程通常需要复杂的组织协作. 而代理, 无需重新编译和重新部署, 就可以升级应用. 同样, 代理允许使用多种语言系统, 应用可以由不同的语言编写, 当然这种方法对于库来说代价是非常大的.
也许对于大型组织来说, 最重要的是, 在代理服务器而不是库中实现 -- 服务网格负责将运行时操作所需的功能提供给服务所有者, 并被这些功能的最终用户掌握 - 平台团队. 提供者和消费者的这种对齐, 允许这些团队掌握自己的命运, 并将 dev 和 ops 之间的复杂依赖关系分离.
以上这些因素共同促成了 Service Mesh 的兴起, 也使运行时操作变得更为健全. 通过部署一个分布式代理的 "网", 可以作为底层基础设施的一部分维护, 而不是维护应用本身, 并通过提供集中的 api 来分析和操作流量, Service Mesh 为整个组织运行时操作提供了一个标准的机制, 同时确保可靠性, 安全性和可见性.
END -
开源 PaaS Rainbond https://www.rainbond.com/ v3.6.0 现已发布, 新增 Service Mesh 微服务架构开箱即用, 通过插件式扩展来实现治理功能, 并支持 spring cloud,api gateway,dubbo 等主流微服务架构.
来源: http://www.tuicool.com/articles/YRJJNza