速记：SFDC 2016 - 青云QingCloud 王渊命 《基础设施服务的微服务化》.docxVIP

主题：2016杭州开发者大会—服务端分会场 时间：2016年12月10日下午1：40 会场主持人：百姓网 贺师俊Hax 议题：《基础设施服务的微服务化》 讲师：青云QingCloud 王渊命 王渊命：刚才题目说错了，可能还没有改过来，我的题目是基础设施服务的微服务化，我叫王渊命，后面是我的ID，是全球唯一的ID，所有的地方见了这个ID就是我。我在青云，青云是一个做IaaS和PaaS服务的公司，我主要关注容器和分布式系统，以及开发工具这块的东西。擅长是Java、Go和Python，下面是我的个人博客。 话题是微服务，大家一直在讨论微服务，我觉得今天我们服务端的话题从早上到下午，90%应该跟微服务是有关系的，也就是说微服务现在是个非常火的话题，比如容器，比如语言，都是在微服务输入，微服务是我们的目标，我们所做的事情是目标下面的。还有一个问题是多微的服务才能叫微服务？有没有标准？微服务应该是几行代码、几个方法、几个接口，没有这个标准。 我们先翻到微服务的始作俑者创造的概念，他创造这个概念的时候，大家关注几个关键词，一个是小的服务，微服务一定是小的；第二个是独立部署，就是你这个服务必须要能独立部署，而不是以库的方式跟其他服务交互，我们以前可能是以不同的库交互，你切入到其他的服务里面调用，现在微服务要求是独立部署。还有一个要求，完全地自动化部署，这一点一般大家谈论微服务的时候，可能很少谈到。为什么微服务要完全地自动化部署呢？这里边有个问题，比如我们现在只有一个服务或者几个服务，我们把它拆成几百个、几千个服务了，我们怎么去管理呢？你如果没有完全的自动化部署，微服务是没法执行的。你如果说我土豪，一千个服务器找一千个人来每人看一个服务，这好像也行，但这不是微服务的目标。 所以我们再回到微服务，很多情况下大家都关注的是前面一部分，就是把它拆，我们把一个大的服务拆开，拆成更小的，用远程调用去解决依赖问题。但是后面还有一层，就是合，我们微服务下所有的系统，应该是一个集群，也就是说它是一个分布式系统的设计思路，互相有关联，要合起来。互相之间需要感知，能自动化操作，这是一个目标，能自动化，必须把它互相感知。 这是一个例子，标准的一个简单的微服务，比如这里有4个服务，每一个服务后面挂自己的缓存和数据库，前面有代理和交互的队列，这是简单的微服务。这里面我们涉及到哪些基础设施服务呢？我们可以看一下，负载均衡器，前面老师也讲了，HAProxy和Nginx这样的。还有数据库，缓存，队列，依赖NoSQL服务，服务发现所依赖的ETCD等服务。 我们这些基础服务是否需要微服务化？我们前面谈到微服务的时候，都谈我们怎么做业务拆分，但是我们业务依赖的这些基础组件怎么处理它？我们看看现在的基础设施服务是怎么解决的，第一是托管给基础设施部门，大公司都很普遍，我们有一个基础设施的部门，有GBA有运维，负责我们线上的数据库和基础库的运维管理。研发说需要一个数据库，然后申请、创建，给我们一个地址再去调它，这是一个基础服务的流程。然后还有托管给云厂商，比如青云，还有阿里云等等，都提供了这种基础服务的组件，点一个按纽创建一个集成然后去用它，现在基本上是这两种解决方案。 但是这两种方案有什么问题呢？第一就是我们这个开发测试流程中的基础设施服务，怎么自动化呢？技术部门是管线上的，我开发的时候需要一个数据库，他来帮你搭个数据库吗？不会干这个事情的，只能研发自己搞。但是研发自己搞的问题是，研发一般没有精力说把这个完全做成一套自动化的东西，或者说你做成自动化了，但是你跟线上的东西是异构的，你现在做的是在开发环境使用或者是测试环境使用，你跑到线上去这套东西又不一样了，线上跟测试环境异构的问题，早上也有老师提到，这是很大的一个坑。然后还有就是我们基础设施服务变了，我们应用怎么知道。我们现在买SQL有两个困惑，我不够了要加一个库，你上线的时候还要修改。如果是微服务也很麻烦，如果说是加了一个存库，我们立刻感知到自动地用了了这个服务，这样会很简单。在现有的体系下比较难以实现，因为它互相不感知。 所以我们再回归到微服务的要求，必须是集群化的设计，要有完全的自动化部署和伸缩。考虑到这两个要求，我们有个结论，基础设施服务也是微服务中的一部分，你不能抛开基础设施服务而只管自己的业务，所以它必须是一体的。它们跟业务服务之间要互相感知到，这是我们的结论。 现在问题又来了，这些服务怎么微服务化？我们自己的业务好像我们自己写的程序，可以控制它，但是基础设施服务，怎么实现它做到这一点？有几个难点，第一是我们基础设施服务多样，配置异构，各种各样的配置方式。还有集群的发现方式也是不一样的，我们现在大多数的基础设施服务都是集群化的，集群的互相发现的机制和互相