干货分享 | 途牛微服务架构快速响应市场变化实录

Posted 2021-01-02 msup

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

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

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

 

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

 

 

1

背景

 

互联网市场是一个“快鱼吃慢鱼”的市场，想要击败别人在市场占有一定份额，就要及时提升自己技术。快速响应瞬息万变的市场正是技术价值体现之一。

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

1. 为什么有些系统会越来越乱。

2. 这样的做法下并不是真正的快，只是为了快速满足业务的需求，搭建了一个存在问题的系统。

3. 不要相信产品说的临时方案，临时最后都会变成最终方案。

    

 

 

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

 

Q：请问当前的架构下，实现服务的无状态化方案是什么？

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

 

Q：如何处理前端页面权限管控问题，避免无权限用户访问页面？

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

 

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

 

 

 

 

2018最新案例征集中

 

TOP100summit是科技界一年一度的案例研究峰会，每年甄选有学习价值的100个技术创新/研发管理实践，分享他们在本年度最值得的总结、盘点的实践启示；TOP100summit于2018年12月1-3日在北京国家会议中心举办，与其在别处仰望，不如来这里并肩。

 

 

入选标准

1. 您带领的产品或项目案例（再或从事的工程实践）具有借鉴价值，能够帮助他人的项目或团队获得启示、成长的长尾效应；

2. 您是一位热爱创新、敏于思考、善于总结经验的“教练”；

3. 谢绝广告、市场化公关演讲，壹佰案例遵循100%案例研究学习为宗旨；

 

 

入选范围

1. 来自科技领域一线研发管理实践及技术创新案例；

2. 截止日期2018年9月30日；

 

如果你或你所在的研发团队有优秀的技术研发创新案例，欢迎自荐加入；如果你身边的朋友也有好的案例，不妨关注壹佰案例获得更多资讯。