七牛技术总监肖勤：微服务架构实践经验分享

微服务架构优势

肖勤首先简单介绍了微服务（Microservices）的内涵及优势，他表示，微服务架构的本质，是用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

微服务架构将服务拆分，分别采用相对独立的服务对各方面进行管理，彼此之间使用统一的接口来进行交流，架构变得复杂，优势也很明显：

• 复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

• 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

• 技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。

• 容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

• 扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

微服务架构实践

肖勤介绍重点介绍了七牛图片处理（FOP）场景的微服务应用。FOP服务早期的架构以它的每一个应用为后端。随着用户越来越多，流量越来越高，负载均衡逐渐出现了带宽和流量的压力。

七牛将图像处理服务拆成两个部分，分别负责处理文件的传输和图像本身的处理。从负载均衡过来的请求不再是完整的文件，而是文件的地址。这样，负载均衡和流量优化跟整个图像处理没有关系，可以做单独的部署。而对于稍微复杂一些的请求（如图片格式和尺寸的变更，添加水印），就用管道的方式把不同的服务串联起来最终实现。

对话肖勤

ImapBox：能否介绍您现在的工作，以及您为什么选择加入七牛？

肖勤：我在3个月之前加入七牛，目前负责基础架构运营、部署相关的研发工作，为基础架构部门的同事提供支持。

选择七牛，我很认同七牛的信念和观点，就是让云服务变成和水电煤一样的基础服务。能够为这样的想法而工作，我觉得还是挺有意思的。技术工作者在不同阶段需要关注和选择不同的东西，这就是我的选择。

ImapBox：那您换了两次工作，也成为了一名技术管理者，从您的经历来看，在不同的时间节点应当关注哪些不同的东西，才符合技术人员的成长路径？

肖勤：刚开始工作的时候，我首先考虑要找到一个能够真正学习技术的平台，正好有一些熟悉的师兄能够引领我。然后来到一家创业团队，多数技术人员基本都没有经验，我就成为了技术决策者，把之前积累的经验变成解决问题的方式。再然后随着云计算的发展，我就加入到基础云服务的构建当中来。

我认为，对于初创公司来说，不存在纯粹的管理者，技术团队都是为产品研发服务的，不可能脱离技术工作。所谓管理，也是针对事情，做研发项目的管理，协调团队把产品做出来。

对于个人职业发展规划，我始终认为，首先一定不能浮躁，时代和技术变化确实都很快，但解决问题的基本技能才是技术人员的根本；其次需要多交流，包括和同事和老板的交流，才能更好地发挥自己的聪明才智。

ImapBox：如何看待加入七牛的工作的挑战？

肖勤：从公司层面说，存储服务基础很好，但其他方面的积累相对要少，还需要继续学习和积累。与此相对应，于我个人而言，背景知识也还有很多需要学习的地方。应对的办法，我认为是多读代码，读书，通过项目试验，以及尖端技术在实践中的使用来获得进步。

ImapBox：您擅长Ruby on Rails，七牛云存储其实用Go，您如何看待不同的语言和框架的选择？

肖勤：我个人对开发工具没有特定的偏好，相信实用至上，不会参与语言的争论。语言、框架都是工具性的东西，都是为产品研发服务的，应当由项目决定。Ruby on Rails是不错的工具，七牛云存储用的Go语言，前端以AngularJS为主，也都非常成熟。七牛公司内部已经有很多的积累，所以也没必要再造车轮。

ImapBox：另外作为以前的云服务使用者，现在的云服务提供者，您感觉有哪些不同？

肖勤：云的基础服务的发展成熟，能够为企业尤其是创业者提供很更好的机会。借助云服务提供者做出的专业服务分担一些事情，企业和创业者就可以有更多的精力投入到自己的核心价值上去，商业上创业成功的可能性会更大。但这需要云产品符合业务运营的逻辑。

作为云服务提供者，我需要保证构建的功能是用户真正需求的。而有了云服务使用者的经历，我能够更好地理解为什么用户会关心某些功能，哪些功能做得还不够好。这对云服务质量的提升很有帮助。

ImapBox：您今天谈到的微服务架构是否代表云服务的成熟？用户如何确定在哪种情况下需要使用微服务架构，哪种情况下不能使用微服务架构？

肖勤：对于做好事情、维护好产品而言，微服务架构不是唯一的方向，但是它是一个比较靠谱的思路和方向。如果你把所有的东西放到一起，都自己来做，势必需要很多资源来维护它，如果拆分开，把一些基础服务部件交给专业做基础服务的人来做，成本通常会比自己做的要低得多。要利用好云计算资源，服务就是拆分越细越好。

对于创业团队来说，我个人认为，不必刻意去追求微服务。尤其在创业初期，首先需要把产品做出来，等到方向得到验证，服务越来越复杂，团队越来越庞大之后，再适当放慢脚步，考虑团队架构、产品架构的调整，如何能够用同样的资源做更多的事情。

ImapBox：能否介绍微服务架构目前在七牛发挥的作用？

肖勤：微服务架构在七牛现在已经是一个潜移默化的影响。微服务架构不仅仅是描述技术架构，同样也是描述团队架构。就像一种服务的精神，你要注意构建、运营和管理这个服务，这样一种精神在团队中是非常有益的，每个人对自己的职责都能够更加清晰地认识，从而发挥主观能动性，包括运营、后期的改进，能够自发地去提升，团队的管理就会更加轻松，效率也会更高。

ImapBox：拆分服务迁移到微服务架构，有没有通用的步骤？

肖勤：首先，企业要有一致的想法，认同微服务架构带来的好处。

其次，这个过程要循序渐进，不能操之过急。不一定是方向的问题，而是执行过程的问题。先挑选边缘的服务、基础性的服务、可替代性强的服务，它们用基础云服务替代，而不是自己维护，或者把多项业务的共通部分拆出来，用少数人来维护，看看这样做是否真的有好处，切实解决问题，节约资源，在有好处驱动的情况下，再决定推进架构变革。如果架构比较特殊，不适合微服务，通过边缘服务的尝试，可以及时发现问题。

ImapBox：对于微服务带来的复杂性，包括不同服务之间的联系和依赖关系等等，用户还有哪些需要特别注意的地方？

肖勤：服务的分拆肯定会让结构更加复杂，但微服务在理念描述上已经意识到，从服务架构着眼，设计上考虑了部署的问题，运营在架构中的优先级也是排在第一位的，而以往在设计模式、软件架构基本不会考虑到部署、运营的问题。所以，如果要支持微服务架构，必须有一套行之有效的运营、部署的工具和方式，这也是容器相关技术和容器云现在备受关注的一个原因。

依赖的问题，包括一部分的复杂性问题，取决于拆分时候边界和接口的定义、数据联通的方式，设计得是不是足够合理，服务提供者是不是清楚需求的方式，服务调用者是不是理解接口的意图，也就是说团队针对每个服务的沟通，对事情的定位，对接口的抽象，是不是有一个同样的认知水平，达成一个共识。只要保证接口稳定、合理，实现不管怎么变化，对整合架构就不会有负面影响。服务的局部修改反而可以更快速，因为不会涉及一个大系统的调整。

所以说，不能为了拆分而拆分，拆分的意图要准确描述问题的解决。在一个系统里面，定义接口比怎么实现更重要，不要设计不好理解、不合理的接口。

ImapBox：谈到容器，您如何看待Docker的兴起给微服务架构带来的机遇和挑战？

肖勤：当前的容器市场很热闹，但Docker还是最具代表性的容器技术，微服务架构的主流技术方案中都使用了Docker，它的一些特性如隔离性、物理机制等和微服务架构有天然的契合度。但是Docker并不能解决微服务的所有问题，它最初是一个单机的工具，虽然后来官方也推出了很多的工具链，要真正解决部署的问题，还有很长的路要走。

ImapBox：具体到实操，您推荐采用哪些工具？

肖勤：我们在考察中发现，Google开源的容器集群管理系统，设计的思路很不错，毕竟Google在这方面是非常领先的，它的容器集群已经成熟应用。使用Kubernetes部署微服务，用户需要的只是定义服务的状态，而不是部署过程。整个调度的过程、提供服务的过程都由系统自动实现。

需要说明的是，虽然Kubernetes目前已经发布1.0版本，它在现在的阶段能为我们提供一个很好的工具，但它不一定是未来，它也有一定的局限性。例如，Kubernetes的设计，Pod的网络与Gloogle云服务高度整合，如果不用GCE，用户还需要自己做很多的工作才能有好的网络服务。这需要企业先去尝试，看看是不是适合自身的情况。

本文为ImapBox原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)