订阅云计算RSS CSDN首页> 云计算

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

发表于2015-08-12 11:03| 次阅读| 来源CSDN| 0 条评论| 作者周建丁

摘要:在近日的七牛开发者最佳实践日上,七牛技术总监肖勤介绍了本人在微服务架构方面的实践经验,并接受了CSDN记者的采访,分享了个人职业经历心得以及如何看待云服务,微服务架构和Docker的发展。

服务的疯狂增长与云计算技术的进步,让微服务架构受到我们的重点关注。在近日的七牛开发者最佳实践日上,七牛技术总监肖勤介绍了本人在微服务架构方面的实践经验,并接受了CSDN记者的采访,分享了个人职业经历心得以及如何看待云服务,微服务架构和Docker、Kubernetes的发展等。

微服务架构优势

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

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

  • 复杂度可控:在将应用分解的同时,规避了原本复杂度无止境的积累。每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。
  • 独立部署:由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程,使得发布更加高效,同时降低对生产环境所造成的风险,最终缩短应用交付周期。
  • 技术选型灵活:微服务架构下,技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。由于每个微服务相对简单,当需要对技术栈进行升级时所面临的风险较低,甚至完全重构一个微服务也是可行的。
  • 容错:当某一组建发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。在微服务架构下,故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错。
  • 扩展:单块架构应用也可以实现横向扩展,就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时,微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。

微服务架构实践

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


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


对话肖勤

CSDN:能否介绍您现在的工作,以及您为什么选择加入七牛?

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

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

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

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

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

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

CSDN:如何看待加入七牛的工作的挑战?

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

CSDN:您擅长Ruby on Rails,七牛云存储其实用Go,您如何看待不同的语言和框架的选择?

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

CSDN:另外作为以前的云服务使用者,现在的云服务提供者,您感觉有哪些不同?

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

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

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

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

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

CSDN:能否介绍微服务架构目前在七牛发挥的作用?

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

CSDN:拆分服务迁移到微服务架构,有没有通用的步骤?

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

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

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

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

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

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

CSDN:谈到容器,您如何看待Docker的兴起给微服务架构带来的机遇和挑战?

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


CSDN:具体到实操,您推荐采用哪些工具?

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

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

0
0