【转】微服务架构实践经验分享

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

微服务架构优点

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

 

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

 

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

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

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

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

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

微服务架构实践

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

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

核心技术：Maven,Springmvc mybatis shiro, Druid, Restful, Dubbo, ZooKeeper,Redis,FastDFS,ActiveMQ,Nginx 
1.     项目核心代码结构截图

   项目模块依赖

特别提醒：开发人员在开发的时候能够将本身的业务REST服务化或者Dubbo服务化

2.    项目依赖介绍

   2.1 后台管理系统、Rest服务系统、Scheculer定时调度系统依赖以下图：
 

       2.2 Dubbo独立服务项目依赖以下图：

 

3.  项目功能部分截图：

 

 

 

 

 

 

 

 

zookeeper、dubbo服务启动 

 

 

dubbo管控台 

 

 

 

 

 

 

 REST服务平台

 

 

 

 

对话肖勤

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，用户还须要本身作不少的工做才能有好的网络服务。这须要企业先去尝试，看看是否是适合自身的状况。