`
壹佰案例
  • 浏览: 34694 次
  • 性别: Icon_minigender_2
  • 来自: 北京
社区版块
存档分类
最新评论

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

阅读更多

本文内容节选自第六届全球软件案例研究峰会,时任途牛旅游网笛风平台事业部研发部部门负责人刘晓涛老师分享《天下武功唯快不破-微服务实践快速响应瞬息万变的市场实录,重点分享:微服务架构特点,微服务架构全过程(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日;

 

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

分享到:
评论

相关推荐

    途牛微服务架构快速响应市场变化实录

    快速响应瞬息万变的市场正是技术价值体现之一。例如,在大的商业环境里有许多不同的业务,每个业务的技术诉求也是不同的,可能是快速上线或者高并发或者按时交付等等诉求。技术方案是为了满足这些对技术的诉求,这也...

    途牛-天下武功唯快不破:微服务实践快速响应瞬息万变的市场.pdf

    - **快速响应瞬息万变的市场**:强调在快速变化的市场环境中,通过微服务架构提高业务灵活性和响应速度。 #### 描述分析: 文档的描述与标题相同,因此不再重复解读。 #### 标签解析: - **微服务实践**:表明了...

    在线旅游订单系统的微服务架构.pdf

    总结而言,微服务架构在在线旅游订单系统中能够有效应对业务的复杂性,通过分离服务、独立部署和灵活扩展,为用户提供更加个性化、快速响应的服务。途牛旅游订单系统的发展历程证明了微服务架构在实际应用中的可行性...

    途牛网站无线架构变迁

    途牛作为国内知名的在线旅游服务平台之一,其无线架构经历了多次重大调整与优化,以应对不断变化的市场需求和技术挑战。 #### 二、发展历程 途牛无线架构的发展历程可以分为以下几个阶段: 1. **2008-2010年**:此...

    小米途牛快的饿了么等大型网站架构技术

    【标题】:“小米途牛快的饿了么等大型网站架构技术” 【描述】:本话题将深入探讨小米、途牛、快的打车(现滴滴出行)以及饿了么等知名互联网公司的大型网站架构技术。这些公司在面对海量用户访问、高并发请求以及...

    途牛供应链系统的架构演进.pdf

    为应对这种大规模的数据和计算压力,途牛采取了一系列架构优化措施,包括服务总线(TSP)、业务公共平台、财务结算平台等,实现了服务的垂直支持、去中心化、异步/离线处理、微服务化/组件化。同时,引入了DB水平...

    仿途牛旅行分享

    【仿途牛旅行分享】这篇文章主要探讨了使用apicloud平台进行Hybrid App开发的经验,特别是如何模仿途牛旅行App的界面和功能。Apicloud是一个强大的混合移动应用开发平台,它提供了一系列丰富的端API,使得开发者能够...

    高性能,高可用,可扩展在途牛旅游⽹的实际经验.zip

    这涉及到一系列的技术策略和架构设计,旨在确保系统能够处理大量并发用户、快速响应请求,并且具备应对突发流量的能力。以下是根据标题和描述可能涉及的一些关键知识点: 1. **负载均衡**:在途牛旅游网这样的大型...

    各大型网站架构讲解

    高建的分享可能涵盖了如何从传统的Web架构转向适应移动设备的响应式设计,涉及到的技术可能有移动APP的开发框架、移动网络优化、推送服务、离线存储和本地计算等。 3. **58同城高性能移动push推送平台架构优化之路*...

    仿途牛源码分享

    【仿途牛源码分享】是一个关于旅游应用开发的项目,它基于APICloud平台构建。APICloud是一个跨平台的移动应用开发框架,允许开发者使用JavaScript进行原生应用的开发,大大提高了开发效率和降低了技术门槛。这个项目...

    途牛旅行网的经营模式分析.doc

    途牛旅行网作为中国知名的在线旅游服务平台,其经营模式的成功与独特性值得深入分析。...通过深入分析其各个模式,我们可以学习到如何在快速变化的市场环境中构建并优化一个成功的在线旅游服务平台。

    途牛 搜狗 高性能-高可用-可扩展商业平台设计

    在文档中,搜狗和途牛可能详细介绍了他们的容错架构,包括如何通过分布式系统和集群实现服务的无中断运行,以及如何在遇到硬件或软件故障时快速恢复服务。 再者,可扩展性是应对业务快速增长的关键。"高性能,高可用...

    旅游网站-仿途牛

    4. Bootstrap或自定义CSS框架:提供预设的UI组件和响应式布局,快速构建美观的界面。 二、后端技术 1. PHP或Node.js:作为服务器端编程语言,负责处理HTTP请求,执行业务逻辑,与数据库交互。 2. Laravel或Express....

    ArchSummit北京-《途牛供应链系统的架构演进》-李源.rar

    ArchSummit北京-《途牛供应链系统的架构演进》-李源。rar,这个资料是一份关于数字化转型解决方案的精品资料。它详细介绍了途牛供应链系统的架构演进过程,以及在数字化转型过程中所采用的各种技术和方法。这份资料...

    途牛网盈利模式分析.doc

    同时,途牛网还不断地创新和改进自己的业务模式,以适应不断变化的市场需求。 途牛网的盈利模式是非常成功的,值得其他企业学习和借鉴。该公司的业务模式非常明确,主要基于旅游产品的预订效劳和特色产品和服务的...

    以途牛商旅为例:看B端产品设计实录 .doc

    【标题】:“以途牛商旅为例:看B端产品设计实录” 【描述】:本文以途牛商旅作为示例,探讨了从C端到B端产品设计的转变,涉及思维模式、用户分析方法以及设计策略。 【标签】:“计算机”、“文档”、“互联网” ...

    途牛旅游项目数据库脚本.rar

    通过对这个脚本的分析和执行,我们可以了解途牛旅游项目的数据库架构,理解其数据模型和业务流程。这对于项目的开发、维护和优化都具有极其重要的意义。 总结来说,途牛旅游项目数据库脚本是实现平台功能的基础,它...

    高性能,高可用,可扩展在途牛旅游⽹的实际经验.pdf

    因此,途牛采用了数据驱动的模型架构,核心层基于业务流程设计,不随具体需求变化,而需求的变化仅影响多维层模型,这样提高了模型的灵活性和可重构性。 在早期的老数据平台中,途牛面临服务器架构伸缩性差、数据...

Global site tag (gtag.js) - Google Analytics