Spotify编目微服务经验
本文讲的是Spotify编目微服务经验【编者的话】Spotify作为一家大规模采用了微服务架构的公司，运行着成百上千的微服务，如何有效地治理微服务生态系统？本文从微服务编目的角度，给大家带来了一些可供借鉴的经验。
天下没有免费的午餐，几乎所有的技术和架构选型都有利有弊。ThoughtWorks的Martin Fowler和他的同事们写了一写关于使用微服务架构时权衡利弊的好 文章 。本文将以Spotify的软件编目系统为例，详细介绍这篇文章中并未涉及的一个重要问题。
微服务架构的一个优点是可以通过强壮的模块边界和独立部署，来帮助你快速地扩展开发团队。因此你可以通过增加团队的数量来加快服务的开发。不过这就像计算机科学中的很多好东西一样，它也是一把双刃剑，因为具有快速扩展服务的能力也就意味着会有更多的服务被开发出来。当你拥有一个包含很多小型服务的大生态系统时，尽管每个服务都非常简单，大量的服务也意味着完全理解生态系统会非常的困难。
Spotify目前大约有100个团队，他们各自独立构建、部署和运行微服务。登记在册的服务大约有1600个，服务发现系统中注册了大约1000个（关于这种差异的详细信息，请见下文），这意味着我们已经无法通过口口相传来找到谁负责一个服务以及它起什么作用了。于是我们使用了名为System-Z的内部工具对我们的服务进行编目。
System-Z的核心是一个称为“sysmodel”的服务，它跟踪我们生态系统中各种微服务的静态配置元数据。这个信息与任何文档都有相同的问题：能提供它的人或者团队不是能从中获益最大的。由于它关乎Spotify整体服务的质量，所以我们鼓励团队保持他们的服务元数据是最新的，例如：
为了自然地获取一些动态数据（运行位置、当前版本等），并提高一些数据的可靠性（其他服务实际调用情况等），我们还通过轮询方式来获取实例的运行时数据。这些元数据会通过我们的后端框架Apollo来创建并发布。
System-Z也已经成为了大多数用于管理后端服务工具的基础，并且大多数这些工具倾向于建立在sysmodel服务提供的数据之上。
sysmodel服务读取的数据实际格式为自由格式的YAML，这意味着用户可以根据自己的需要自由添加自己服务的元数据。当我们在2015年5月启动它的时候，我们决定在Spotify中公开sysmodel服务。在2016年9月回顾它时，我们发现了至少18个不同的使用案例，从业务规则定义的服务器访问控制（X服务的拥有者团队将获得Y服务器的登录权限），到自动更新各个团队的监控面板。大多数sysmodel服务提供数据的使用方式是我们构建它时没有预料到的。
原文链接：Cataloging Microservices（翻译：刘思贤）
===========================================
译者介绍
天下没有免费的午餐，几乎所有的技术和架构选型都有利有弊。ThoughtWorks的Martin Fowler和他的同事们写了一写关于使用微服务架构时权衡利弊的好 文章 。本文将以Spotify的软件编目系统为例，详细介绍这篇文章中并未涉及的一个重要问题。
微服务架构的一个优点是可以通过强壮的模块边界和独立部署，来帮助你快速地扩展开发团队。因此你可以通过增加团队的数量来加快服务的开发。不过这就像计算机科学中的很多好东西一样，它也是一把双刃剑，因为具有快速扩展服务的能力也就意味着会有更多的服务被开发出来。当你拥有一个包含很多小型服务的大生态系统时，尽管每个服务都非常简单，大量的服务也意味着完全理解生态系统会非常的困难。
Spotify目前大约有100个团队，他们各自独立构建、部署和运行微服务。登记在册的服务大约有1600个，服务发现系统中注册了大约1000个（关于这种差异的详细信息，请见下文），这意味着我们已经无法通过口口相传来找到谁负责一个服务以及它起什么作用了。于是我们使用了名为System-Z的内部工具对我们的服务进行编目。
System-Z：软件编目工具系统
System-Z包括一组微服务（很显然）和一个Web UI（见右上）。System-Z的核心是一个称为“sysmodel”的服务，它跟踪我们生态系统中各种微服务的静态配置元数据。这个信息与任何文档都有相同的问题：能提供它的人或者团队不是能从中获益最大的。由于它关乎Spotify整体服务的质量，所以我们鼓励团队保持他们的服务元数据是最新的，例如：
- 将元数据与代码一起存储，可以清楚地突显元数据和代码的所有者。
- 如果元数据良好，可以更方便地使用工具来管理服务。
- 如果数据维护不及时，将显示警告和提示，促使工程师的强迫症来维护它。
为了自然地获取一些动态数据（运行位置、当前版本等），并提高一些数据的可靠性（其他服务实际调用情况等），我们还通过轮询方式来获取实例的运行时数据。这些元数据会通过我们的后端框架Apollo来创建并发布。
System-Z也已经成为了大多数用于管理后端服务工具的基础，并且大多数这些工具倾向于建立在sysmodel服务提供的数据之上。
模型
在sysmodel数据模型中，一些核心的概念包括：- 软件组件（Software component） ，虽然System-Z和sysmodel是为了支持我们的微服务而开发的，但我们不仅用来跟踪微服务，还包括数据处理管道、库以及像Jenkins这种第三方工具等。
- 角色（Role） ，角色是一种我们扩展到一定数量的用户，或者部署一定数量的可用区到指定的地理位置等的功能。例如“登录”，这个允许Spotify的用户可以登录。角色通常在（虚拟）主机上实例化，并且需要一个或多个组件在主机上运行才能工作。角色通常水平缩放到足够数量的主机。Kubernetes Pod就是这个概念很好的例子。
- 项目（Project） ，一组相关的角色，例如“登录”角色和包含用户数据的存储。
- 模板（Recipe）， 为了运行一个角色，必须在主机上同时安装软件组件的描述，例如Kubernetes pod模板就是这个很好的实现示例。
- 发现名称（Discovery name） ，为了表示微服务之间的依赖关系，我们使用发现名称。这允许我们间接做一些事情，例如在现有服务之前插入代理，用于缓存、升级和灰度上线，在不停机的情况下进行改进。部署的组件可以注册0到多个发现名称。
- 所有者（Owner） ，在我们目录中关于软件最常问到的一个问题是：“是谁的服务？”，因为知道所有者，就可以去问他，如何用这个服务来做某事了。
sysmodel服务读取的数据实际格式为自由格式的YAML，这意味着用户可以根据自己的需要自由添加自己服务的元数据。当我们在2015年5月启动它的时候，我们决定在Spotify中公开sysmodel服务。在2016年9月回顾它时，我们发现了至少18个不同的使用案例，从业务规则定义的服务器访问控制（X服务的拥有者团队将获得Y服务器的登录权限），到自动更新各个团队的监控面板。大多数sysmodel服务提供数据的使用方式是我们构建它时没有预料到的。
结论
微服务架构给团队和开发者带来的很大的自由，它允许分散地创建许多小的组件，这大大提高了实验和学习的速度，但是也导致了软件数量的增加，这反过来让整个软件生态系统变得难以理解：什么应该在那里？谁拥有它？如何宏观地看到它们？是否可以弃用它？System-Z这样的微服务编目系统可以简化理解，也可以作为与后端系统一起工作的其他工具的基础。原文链接：Cataloging Microservices（翻译：刘思贤）
===========================================
译者介绍
刘思贤 ，爱油科技架构师，PMP，关注互联网相关技术与软件项目管理，是一名DevOps实践者，乐于整理和分享一些实践经验。
原文发布时间为：2017-01-07
本文作者：刘思贤
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：Spotify编目微服务经验
