专注于Java领域优质技术，欢迎关注

作者：刘晓涛 壹佰案例

本文内容节选自第六届全球软件案例研究峰会，时任途牛旅游网笛风平台事业部研发部部门负责人刘晓涛老师分享的《天下武功唯快不破-微服务实践快速响应瞬息万变的市场》实录，重点分享：微服务架构特点，微服务架构全过程。（PPT+文稿）。

刘晓涛老师时任途牛旅游网笛风平台事业部研发部部门负责人，途牛架构委员会成员，2008年加入途牛，先后参与过多个核心系统的开发，经历过系统资料的爆炸增长、系统架构的迭代升级、研发团队的规模壮大、业务需求的不断增多，并在期间从事系统设计、开发、效能优化、故障解决、程式码重构、专案管理等工作。致力于在面对需求多迭代快的残酷现实下，如何保证系统高可用、高效能、易扩充套件、可伸缩。

编者按：2017年11月9-12日，第六届全球软件案例研究峰会在北京国家会议中心盛大开幕，现场解读2017年“壹佰案例榜单”。时任途牛旅游网笛风平台事业部研发部部门负责人刘晓涛老师分享的《天下武功唯快不破-微服务实践快速响应瞬息万变的市场》实录。

【内容简介】随着业务的不断变化与扩充套件，微服务是当前可满足业务需要的同时，保障系统质量，提升研发效能的最佳选择。本案例以旅游平台的系统建设为例，介绍当系统要支援一个新的业务时，如何能够快、准、好的实现，以及微服务架构的整体过程与思路。最终实现了协作效率提升大约20%。交付周期缩短30%，系统故障大幅减少。

1 背景

例如，在大的商业环境里有许多不同的业务，每个业务的技术诉求也是不同的，可能是快速上线或者高并发或者按时交付等等诉求。

技术方案是为了满足这些对技术的诉求，这也是技术的价值体现。

总结而言，技术本质上是为业务服务，无论是架构师还是底层开发，都应重视业务与技术的结合。

这里的“快”指的是一如既往的持续性的“快”，而不是断断续续的。而且随着公司规模变大，业务增多，出于成本的考虑，我们会更希望从技术上提升系统和开发人员的效率。

下面是一个在公司里经常会发生的情况。

业务人员提出一个希望能尽快上线的需求，但技术人员需要比较长的时间进行开发。这时候，产品和开发沟通后，可能会提出做一个简单的方案临时使用，后期再进行优化。

但随着时间的推移和其他客观原因，临时方案最后就变成了最终方案。在这样的场景下，极有可能会为未来埋下隐患。

在这个事例里解释了三个问题：

为什么有些系统会越来越乱。这样的做法下并不是真正的快，只是为了快速满足业务的需求，搭建了一个存在问题的系统。不要相信产品说的临时方案，临时最后都会变成最终方案。

2 问题分析

1.业务妥协欠下的业务债。也就是所谓的“临时方案”。

2.系统无秩序的增长。这主要体现在系统越来越大，程式码愈加冗余，模组间耦合度高。上线质量差，为了解决一个BUG结果引入更多的BUG是我们当时经常遇到的情况。

3.研发人员的流动。核心研发人员离开之后，新的研发人员对之前的文件和系统都不够了解，导致让“接码侠”来维护系统，系统越来越差。

接码侠

在中大型团队中，存在一些很大很乱的系统，很少有人敢去维护，但系统对业务又十分重要。此时公司可能会招一些人维护系统，新招的人被称作“接码侠”

问题的特征

短期看来促进业务发展，长期看来阻碍业务发展。在最开始为了支援业务，系统越做越大，但发现把系统作大后对业务的支援越来越差。具有一定普遍性。解决问题变得心有余而力不足。一开始发现问题的时候，认为问题可以忍耐。直到无法忍耐的时候，发现解决变得十分复杂。

3 微服务

微服务没有一个固定的标准，更多的是经验的总结。因为它不是被发明出来的，而是从现实世界中总结出来的一种趋势和模式。

下面的内容，将会介绍途牛团队的经验，告诉各位在什么时候如何去做。

微服务的特征

面向服务：把一个系统按照提供服务型别的不同，拆分成不同的服务。单一职责：每个服务只做自己的事情。微：每个服务下的团队小。自治：每个微服务有自己的独立通道，不会相互打扰。

4 微服务的实践

在拆分之前，要问自己三个问题：

1.是否下定决心。因为微服务需要投入大量的资源，还会有失败的可能。

2.是否对自己的业务系统有充分的了解。如果对自己的系统没有充分的了解，不建议做微服务，否则会有极高的风险。

3.是否具备实施微服务的条件。技术上的自动化水平；团队的组织架构的管理；公司或者整个行业是否支援微服务。

下面我们将以旅游系统为例，讲解微服务的拆分。

团队将系统拆为三个层面：应用层、服务层和支援层。

应用层：对业务模型进行分类，分为不同的主体。

服务层：把业务的功能按照服务的内容进行分类，并把服务从上自下的逐步细化。

支援层：是技术支援的主线，比如有服务框架、容器、监控等。

问题

基础公共服务抽象。例如发票服务是通用的服务，不需要每个业务都实现一遍，可以将其提取成一个公共的服务。服务拆分的边界。对于有些服务按照不同的划分规则会被拆分到不同的服务内，所以在最开始时团队要约定好拆分的边界。拆分的粒度。微服务的拆分是一个循序渐进的过程，从大到小从粗到细，没有办法一开始就拆分成最细的粒度。服务的互动

原则：互动一定要提前约定好。

途牛团队是按照下述五个重要原则约定的。

统一规范错误码。呼叫方和服务方容错处理。界面文件。通过工具自动生成文件，清晰明了。界面技术的无关性。界面的相容性。对外相容，界面内部不被外界感知。互动没做好，可能出现的后果

场景一：由于双方统一规范没有执行，导致双方沟通出现问题。

场景二：引数过滤。

场景三：服务方与消费方的界面相容问题。

服务技术选择型

容器

容器技术是微服务技术最重要的一环。微服务的概念在很早就出现了，但是直到Docker的出现解决了部署复杂，运维成本高的问题，微服务技术才更多的进入大众的视线。

如上图。在以前，部署一个服务需要一天甚至更久，部署好后需要要解决一致性问题，搭建三个服务甚至需要一周时间。

在Docker内，把服务A搭建好后，为服务A打造一个映象复制服务B,C。在一天时间内即可部署三个服务。同时，由于三个服务是统一的映象，天然的解决了环境一致性问题。

服务框架

服务框架的选择与选择电脑组装商户十分相似，要求有一定的口碑和靠谱的硬件提供商；可以提供一站式服务，满足多种需求；安装拆卸方便，升级替换简单快捷。

以Spring Cloud为例，它具有完整的体系，能满足微服务的所有需求，且元件服务标准。

在这个框架下，可以做到组装方便，快捷管理微服务。

注册中心特点

1.将所有的服务统一管理，把所有服务编成一个有机整体。通过组织对外提供服务。例如滴滴平台出现后，个体司机在滴滴注册，由滴滴平台进行对外业务。

2.呼叫不再建立传统的IP＋埠的形式，而是通过服务名进行呼叫。

3.便于外界发现和使用，否则十分容易被人遗忘或忽略。

服务重构

重构的目的是调整程式的呼叫，提高软件的扩充套件性和维护性。

重构时要考虑三件事情。

前后端分离。不影响业务。在业务上有两个原则代价最小原则，影响最小原则。

资料。之前资料的查询是在SQL内，在把产品和订单独立到服务之后，每个服务都会有自己独立的数据库。在资料迁移时，团队将SQL查询改为界面呼叫。但是在订单库和总库之间会存在一些问题。后来，我们选择了双向同步的方式，保证总库资料与独立库资料一致。服务管理

重构后上线业务会增多，但也带来了其他的问题。主要原因如下：

没有统一的规范管理服务执行情况未知呼叫关系复杂服务不稳定安全性解决方法

上下线流程。只有经过架构师审批的服务才可上线。下线时会先把服务状态改为待下线状态，直到服务没有占用才真正的下线。监控体系系统图的绘制促销时预估新增资源，提前做好准备

敏捷与精益

由于微服务与精益敏捷契合度十分高，团队采用了敏捷和精益的方式。

PDCA原则：

P-计划 D-执行 C-执行后的效果预期 A-循环不足之处后再从P开始优化。

这是一个通过循环往复的过程以得到持续不断的必胜。

SDCA：是一个标准化循环，只有持续转动循环，系统才能将之前获得的提升保持下去。

这两个循环相辅相成，一个不停地改善，一个把不停地改善成果坚持下来。

持续交付

可以自动的构建，部署，释出。将敏捷跟精益的实践做的更标准化，自动化。流水线操作。（将构建，部署，释出按照一定的编排进行设计）持续交付的意义

能持续为使用者提供价值，持续收到使用者反馈，持续制定更好的生产策略。

“快”的升级：DevOps理念

5 总结

开始阶段-传统应用架构和微服务架构的取舍

发展阶段-传统应用架构和微服务架构的取舍

微服务的好处与不足

好处：

易扩充套件技术栈不受限弹性：一个服务挂掉，不会影响整个系统不足：

破坏DRY原则，程式码会重复返工：建模一旦出现问题就会返工影响组织架构分散式复杂网络环境制约：一但网络挂掉，系统就会瘫痪事务一致性协作成本：沟通成本高需要投入

Q&A

A： 我们现在开发了一个TSP框架，这个框架可以满足所有服务无状态化去实现的方案。框架本身，是通过框架协议让界面被呼叫。

Q：如何处理前端页面许可权管控问题，避免无许可权使用者访问页面？

A：因为样品提供的平台是B2B，并不是所有使用者都可以用。只有注册使用者才能访问所有的页面，否则的话只能访问一个平台的说明页面。所以我们在最前端做了一个SQL：访问的时候除了说明页面外，访问其他所有的页面必须处于登入的状态。并且我们有一个模组，专门处理平行许可权的问题，保证了分销商只能看到自己的资料。

以上内容来自刘晓涛老师的分享。