Service Catalog（服务目录)是Kubernetes社区的孵化项目Kubernetes Service Catalog Project，旨在接入和管理第三方提供的Service Broker，使kubernetes上托管的应用可以使用service broker所代理的外部服务。
本文将为大家回顾Service Broker的历史与发展。
源起
Service Broker其实并不是kubernetes原生的概念，它源自于Pivotal公司在2011年开源的PaaS(Platform-as-a-Service)项目Cloud Foundry(以下简称CF)。
PaaS上托管的应用经常需要使用诸如数据库，分布式缓存，应用服务器之类的通用的基础设施软件，例如用户要在PaaS上托管一个Web应用的后端，那么肯定会需要MariaDB，Tomcat或者Nginx。传统的方式是在Web应用的编排里把应用依赖的MariaDB/Tomcat/Nginx也创建出来，进行相应的配置并与Web应用集成，这使开发者在开发应用的同时还需要花费大量时间去解决应用所依赖的基础设施软件的部署和配置，增加了应用托管和迁移的成本。
在理想的PaaS环境中，应用开发者应该专注于应用本身的开发，通用的基础设施软件应该由PaaS平台以服务的形式来提供，其可用性和按需动态伸缩能力也应该由平台自身来保障，应用和服务之间应该是松耦合且能够动态集成的；开发者以服务的方式按需消费应用所依赖的基础设施软件，而不需要了解服务的实现细节，也不用担心服务的可用性。
Open Service Broker API
CF的设计者为了实现基础设施软件或其它第三方软件的服务化，设计了一套开放服务代理协议（即Open Service Broker API，以下简称为OSB API）。通过OSB API可以将任意软件快速集成到CF环境中，软件自身可以托管在CF环境内，也可以在CF环境之外独立运行，甚至可以是来自互联网上的SaaS供应商(比如可以把AWS上的提供服务接入到私有的CF环境，只要CF环境可以访问公网)。通过实现OSB API，任何第三方软件提供商都可以把自己的软件以服务的形式对接到CF中，供CF上托管的应用使用。
我们可以看到在CF的架构里，Service Broker处于整个系统的服务抽象层，CF中所有的服务都由service broker接入和管理：
OSB API本质上是对服务生命周期的抽象，包括了七个原语(Primitive)：
- 服务目录(Catalog)：提供对服务内容的描述信息
- 服务实例创建(Provisioning)：创建服务实例
- 服务实例更新(Updating)：更新服务实例
- 获取服务实例状态(Polling last operation)：由于Provisioning/Updating/Deprovisioning三种操作提供异步调用，所以需要一个单独的API来查询操作进度
- 服务实例绑定(Binding)：将服务实例与应用绑定，使应用可以使用服务实例
- 服务实例解绑定(Unbinding)：解除服务实例与应用的绑定
- 服务实例销毁(Deprovisioning)：删除服务实例
(详细规约请参见Open Service Broker API)
关于OSB API的实现，有几个概念需要阐述如下：
- Service Broker：任何实现了OSB API的软件实体都称之为Service Broker，一般可以实现为一个REST Server
- Service/Backing Service：Service Broker所代理的服务(一般也把独立于CF环境运行的服务称为外部服务)，一个Service broker可以代理一个或多个服务，取决于具体的业务需求
- Service Instance：服务实例，可以是承载服务的一个组容器，虚拟机或者只是服务的一个租户(例如一个MySQL数据库实例)
- Service Plan：服务计划，描述了服务的QoS，例如服务实例的资源使用情况
Cloud Foundry vs. Docker/Kubernetes
作为开源PaaS平台的先行者，CF支撑了众多PaaS平台的发展，例如IBM基于CF打造了企业级PaaS公有云平台IBM Bluemix(同时也是目前规模最大的CF项目)。CF在设计之初是面向Application的PaaS，而不像当前大多数主流的PaaS平台那样是面向Container的(即container-as-a-service)。CF的应用托管方案是在应用的jar包或者gem包(早期的CF只支持Java和Ruby两种runtime)和兼容Heroku风格的buildpacks的基础上生成droplet(类似于docker镜像)，然后把droplet运行在CF原生的容器方案Warden里；CF并没有把底层容器管理接口暴露给用户，用户只负责应用本身的构建，打包以及buildpack脚本的开发。
CF具有如下几个比较显著的缺点：
- CF原生的容器方案Warden和应用托管是绑定在一起的，Warden只为CF服务而不像Docker那样可以单独在开发环境中部署使用，同时也缺乏良好的社区活跃度，始终只有CF自己在玩
- CF不支持Docker
- CF的架构较为笨重，可扩展性不强，部署运维难度高，所以一直都是类似IBM，华为这样的重量级玩家在利用CF搭建自己的PaaS
当2013年，Docker横空出世成为容器标准的时候，大多数开发者都开始将Docker镜像视为标准的应用打包方式，而CF不支持Docker就成为一个很大的问题。Docker对PaaS平台的一个重要意义就是，应用的打包，依赖管理，迁移以及升级都由Docker解决，Docker屏蔽了有关应用执行环境的细节；PaaS平台不再像CF那样需要自己实现不同编程语言的执行环境，应用打包以及容器管理方案。PaaS的设计被简化成了CaaS（Container-as-a-Service），PaaS只需要管好Docker容器就可以了。
2014年互联网顶级大厂Google开源了Kubernetes项目(以下称为k8s)，k8s为Docker容器提供了优秀且高度可扩展的编排和集群管理能力。Docker提供的应用打包能力和k8s提供的容器编排和集群管理能力，使用户可以在不依赖CF的情况下快速构建自己的PaaS平台，将已经docker化的应用迁移上去。自k8s面世之后，市场上基于Docker和k8s的PaaS公有云和私有云也如同雨后春笋般出现了，例如Redhat的OpenShift/OpenShift Origin，网易的蜂巢，亚信数据的DataFoundry等，而IBM Bluemix也在2017年初宣布支持Kubernetes作为容器编排引擎。Docker和k8s成为了PaaS生态圈的标准玩法，CF社区逐渐被边缘化。
虽然CF也试图通过Lattice项目(用Diego＋Garden架构替换早期的DEA+Warden架构)支持编排Docker容器，但是已经为时过晚，市场已被Docker和k8s占领。CF可以说是起了个大早，赶了个晚集～
OSB API in Kubernetes
虽然k8s已经成为了当前标准的容器编排方案，但是k8s本身的架构也在不断的演化中，这个过程中也在不断吸收其它开源项目的优势来充实自己。
k8s在设计之初没有考虑过外部服务接入的问题，kubernetes假设所有的应用都是以容器的形态存在，且运行在k8s管理的docker集群之内。而正如我们上文提到的，PaaS上托管的应用经常需要使用诸如数据库之类的通用的基础设施软件，如果没有一个统一的服务抽象层，就必须由用户自己写k8s编排把应用依赖的基础设施软件或其他的第三方软件拉起来，而且这些软件的容器只能在k8s集群内运行，消耗集群资源。
服务抽象一直是k8s需要增强的特性，然而这也正是CF所提出的OSB API解决的问题。于是k8s社区从1.6开始，发挥"拿来主义"的精神，启动了孵化项目Service Catalog，旨在利用OSB API来构建自己的服务抽象层。
我们下一篇文章将着重讨论如何在K8S上使用Service Catalog。
