国内最全IT社区平台 联系我们 | 收藏本站
华晨云阿里云优惠2
您当前位置:首页 > 服务器 > 七牛技术总监肖勤:微服务架构实践经验分享

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

来源:程序员人生   发布时间:2016-12-05 13:50:01 阅读次数:4985次

服务的疯狂增长与云计算技术的进步,让微服务架构遭到我们的重点关注。在近日的7牛开发者最好实践日上,7牛技术总监肖勤介绍了本人在微服务架构方面的实践经验,并接受了恩威科技(微信公众号:天府云创)记者的采访,分享了个人职业经历心得和如何看待云服务,微服务架构和Docker、Kubernetes的发展等。

微服务架构优势

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

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

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

微服务架构实践

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


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


对话肖勤

CSDN:能否介绍您现在的工作,和您为何选择加入7牛?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对创业团队来讲,我个人认为,没必要刻意去寻求微服务。特别在创业早期,首先需要把产品做出来,等到方向得到验证,服务愈来愈复杂,团队愈来愈庞大以后,再适当放慢脚步,斟酌团队架构、产品架构的调剂,如何能够用一样的资源做更多的事情。

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

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

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

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

其次,这个进程要按部就班,不能操之过急。不1定是方向的问题,而是履行进程的问题。先挑选边沿的服务、基础性的服务、可替换性强的服务,它们用基础云服务替换,而不是自己保护,或把多项业务的共通部份拆出来,用少数人来保护,看看这样做是不是真的有好处,切实解决问题,节俭资源,在有好处驱动的情况下,再决定推动架构变革。如果架构比较特殊,不合适微服务,通过边沿服务的尝试,可和时发现问题。

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

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

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

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

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

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


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

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

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

【参考浏览书籍】

1、《微服务架构与实践》(王磊)【摘要 书评 试读】- 京东图书 http://item.jd.com/11826753.html

2、大型散布式网站架构设计与实践 PDF扫描版[69MB] 电子书 下载-脚本之家 http://www.jb51.net/books/323694.html

生活不易,码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
程序员人生
------分隔线----------------------------
分享到:
------分隔线----------------------------
关闭
程序员人生