同程旅游微服务最佳实践

本文首发胖波聊架构界,微信公众号:xiaobo2as

本文概要

  • 导言
  • 微服务拆分的四个维度
  • 微服务应该如何维护版本
  • 如何从单体架构平滑过渡到微服务
  • 结语

一、导言

同程微服务从立项到实施推广已经走过了整整两个年头,从最初的简单粗糙到今天的精细完善,接入服务数量也实现了从1到10,000+的增长。

微服务开发团队和大家一起踩过了无数的坑,最终打造了今天的DSF2.0平台。回顾爬坑记录,现整理一些爬坑心得体验供大家参考,也斗胆提出一些最佳实践以抛砖引玉。

下文将从开发者角度对微服务如何拆分, 版本管理和单体到微服务过渡等方面给出一些建议,  供大家斟酌。

二、微服务拆分的四个维度

从单体架构到微服务,拆分粒度很难把握。理论方法莫衷一是,我们推荐快刀斩乱麻按照如下四个维度做拆分:

团队组织结构

发布升级频率

逻辑调用频率

数据读写分离

1.  团队组织结构

按照康威定律的说法,组织结构一定会反映到系统架构上,同程是树形结构+底层网状结构,那么服务之间一定是每个系统的架构呈明显的树状,但是系统之间会有多重的服务互访。

微服务设计要充分考虑哪些是自用(inner),外部访问(outer)和混用(mix)服务,并尽可以能将其迁移对应的服务组里。

2.  发布升级频率

新老项目由于处于生命周期的不同阶段,修改和发布频率会有很大差别。应该尽量将处于生命周期中不同阶段的接口分割,避免高频更新服务和低频更新服务捆绑,避免向稳定运行的服务组添加新业务接口,而是应该考虑在新的服务组中实现。

3.  调用频率

服务组中的不同服务调用频率会有巨大差别,而高频调用肯定会占据更多的资源,会出现个别接口耗尽资源导致同组接口一起失败(资源竞争),需要对高频访问的服务设置定制的运行策略,如分配更多的CPU核心数和内存, 调整部署使其尽可能靠近数据源等策略,但是如果将所有服务宿主都做成高配,会造成巨大的资源浪费事实上也没有必要,所以应该将高低频访问的服务分割以使其能为获得更好的性能和可靠性做针对性优化。

4.  数据读写分离

上一维度其实已经涵盖了读写分离的一部分,但是为了突出读写分离的必要性,这里单独列出。一般数据操作模式分为CQRS和CRUD两种模式,各有优缺点。 

从操作是否对数据本身造成影响来看,可以粗略的分为读写两类 , 一般来说写操作的频率会大大低于读操作,写操作经常会有更严格的认证授权机制,一般为内部(inner)调用。这些和读操作都有巨大差异性, 因此建议流量较大或较为核心的服务应该做读写分离,分拆为两个服务组发布。

最后分享一个粒度控制的小技巧,大多数情况出现在系统里的每个名词都会在存储层面拥有一席之地,对应一个独立的数据表或库,所以系统里出现的名词都可能是一个潜在的微服务。 

三、微服务应该如何维护版本

微服务治理中维护一个有序,直观的版本会给系统开发过程和服务依赖管理带来巨大的便利,反之无版本或混乱的版本升级策略迷惑开发和设计人员并带来意想不到的依赖问题。良好的微服务治理应该包含一整套完整的版本升级策略,根据我们长期的爬坑实践我们推荐如下版本策略:

1.  使用标准语义化版本

具体参见 语义化版本 2.0.0  。使用标准的语义化版本能使大家保证对版本有统一的理解,应尽量避免自行定义版本语义。DSF 版本推荐使用SemVer 约定,略有不同的是DSF推荐四位版本号(1.2.3.4),前两位作为主版本(1.2), SemVer版本一般为三位(x.y.z 对应:主版本号.次版本号.修订号)。

2.  面向契约设计

当一个团队选择微服务作为服务化实施平台时必须明确微服务化有一个较高的门槛,需要团队自身已经是一个较为成熟运作体系,例如有实施前有完善的架构设计,团队成员有明确的职责划分,团队成员对服务内聚和服务耦合有明确的认知。

上述的这些方面都会促成一个结果: 使设计开发的服务接口最终具有良好的抽象并体现出规划性,最终能够在服务实施前就能交付有良好兼容性的服务契约。实践中体现为一个版本迭代新增、修改、删除的任何部分都是经过慎重思考并体现在服务契约里,实际开发不轻易的修改和增添服务接口。 

3.  并行开发中版本的维护

微服务化对开发体系的一个重大影响就是开发实践的并行化,微服务使开发者从单体架构的调用丛林摆脱出来,使开发者能够把视野聚焦到调用链中其中一环上而不用过多关心上下游的具体实现。

需要付出的成本就是如何避免重复实现以及代码Merge时的更高频的冲突问题,有一个良好的版本管理习惯能够解决绝大部分的Merge冲突问题。

我们推荐在面向契约设计的基础上进一步延伸,通过团队内沟通确定不对外暴露的核心部分由谁来负责并约定在特定的版本实现,而负责使用该核心模块的其他开发者在该版本上递增版本。 

被其他组件依赖较且可能频繁改动的内核代码独占一个特定的版本区间(例如:v1.2.3.0~1.2.3.10作为核心模块的独占版本,依赖该组件的模块必须大于v1.2.3.10),能很好隔离并行开发带来的版本冲突问题。

因为引用核心组件的上层实现彼此没有太多联系,总是能够很好处理Merge带来的冲突问题。

4.  版本的兼容性

能根据版本号判断服务是否向后兼容是服务依赖管理的一个很重要的方面,大多数时候做一个使服务不在向后兼容的决定是很难的事,但是不断的向后兼容的结果往往是服务体量不可控制的增长和系统复杂度的非线性上升。

开发者需要慎重思考并在合适的时间做出服务不再向后兼容的决定,良好的版本策略能将服务是否向后兼容明确的表达出,显式的告诉调用方这是一个不兼容的升级更新, 请务必确保仔细阅读的新的契约文档并做了足够的测试。

对DSF来说不兼容升级是很醒目的,只需观察服务组的大版本号(版本号的前两位,如v1.2.3.4,大版本号为1.2)是否增加,任何服务契约修改都被认为是不兼容的升级,包括删除接口、修改接口名称/参数等,都必须升级大版本号, 而修改小版本号(版本号的后两位,如v1.2.3.4,小版本号为3.4)则代表兼容性升级,如新增了服务接口,代码逻辑优化和Bug fix但是未修改服务契约。

四、如何从单体架构平滑过渡到微服务

一旦决定在开发实践引入微服务架构,如何将积累下来的庞大的巨无霸系统润物细无声的的过渡到微服务架构将是一个巨大的挑战。

推倒重来激进革命路线是要不得的,架构师们最想通过微服务化取代的部分往往是公司的主要盈利核心,改造难度不亚于飞行中更换引擎。从业界公开的信息来看还没有哪家做到了完美升级, 更多的可能无外乎两种:

第一种改造后苟延残喘,研发疲于奔命; 

另一种则是改造中就直接休克。  

因此为使微服务能顺利的应用,架构师从不应该幻想一蹴而就,无数次的碰壁后我们给出如下的爬坑建议:

1.  培训先行

工作技术人都很善于把面临的问题变成技术问题,然后在自己最擅长的领域里取解决掉。这就造成一个悖论:能用技术解决的问题就不是问题,真正的问题在受限的情景下仅靠技术是解决不了的,实施微服务最大的拦路虎也不是技术本身。

从我们的实践来看,最大的问题不是如何做好微服务,而是就微服务应该是什么达成一个一致的看法。

正所谓林子大了什么鸟都有,对于微服务100个人可能就有100种理解,这个不是说我们都是用dubbo或者都是用spring boot就能解决的。

我们的推荐做法就是实施前通过多数人参与的大讨论和培训,让多数人能达成一致的认识,微服务是什么,微服务不是什么? 运用在哪些场景是适合,应用在哪些场景里是不适合的? 结果不要跑的太偏就行, 和编码规范中命名规范一样,使用那种命名方法不重要,重要的是大家都使用同一种命名方法。

2.  绞杀者模式

绞杀者模式指对于无法通过修缮者模式改进的系统通过在系统外重新构建新功能的方式逐步剥离重构,对功能服务逐个绞杀。

好处是不影响原来的环境,一旦条件成熟就能快速切换。

不好的方面则是可能需要有一段时间同时维护两套系统,付出额外的开发维护成本。

3.  监狱模式

还有一种同程内部称之为监狱模式的做法,允许一些短期无力改动的系统通过监狱窗口(MicroProxy)接入微服务平台并委托Proxy将其暴露成微服务, 单体架构往往拥有庞大的服务接口梳理, 往往需要开多个监狱窗口。

每个监狱窗口都会被包装分割成微服务,条件成熟了能很方便的替换成原生微服务,称为刑满释放。

五、结语

市面上微服务的理论和讨论铺天盖地,其中不乏侃侃而谈的大块文章,深入阅读确常常发现大都是新瓶装旧酒或者拼凑篇幅之作。特点是在务虚处浓墨重彩,高谈理论,于实践处则一笔带过,仔细探究则实无一物。

所以如果发现有些技术书籍晦涩难懂,满篇的高大上,读完头脑发胀,确无所进益可能不是您水平不够,更可能是作者故弄玄虚。最近读书有感,书于此,博君一晒。

原文链接:https://mp.weixin.qq.com/s/2H0U8lKW50mLBGeBGLfQpA

Image placeholder
IT头条
未设置
  96人点赞

没有讨论,发表一下自己的看法吧

推荐文章
一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

springDataJpa 最佳实践

springDataJpa最佳实践 前言 SpringDataJpa框架的目标是显著减少实现各种持久性存储的数据访问层所需的样板代码量。SpringDataJpa存储库抽象中的中央接口是Reposit

团队开发中 Git 最佳实践,不给队友拖后腿

今天跟大家分享下团队开发中Git最佳实践的知识。0前言在2005年的某一天,Linux之父LinusTorvalds发布了他的又一个里程碑作品——Git。它的出现改变了软件开发流程,大大地提高了开发流

走进龙岗“智慧大脑” 见证IOC的最佳实践

这里,拥有全球首例地铁5G超宽带车地无线通讯;这里,借助AI、5G、物联网等技术推动工地现场科学化和智能化管理;这里,构建了开放兼容的统一政务云平台;这里,建设了先进、安全、智能的标杆园区;这里,就是

Docker最佳实践:5个方法精简镜像

本文记录了精简Docker镜像尺寸的必要性及好处精简Docker镜像的好处很多,不仅可以节省存储空间和带宽,还能减少安全隐患。优化镜像大小的手段多种多样,因服务所使用的基础开发语言不同而有差异。本文将

Code Review最佳实践

我一直认为CodeReview(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题。包括像Google、微软这些公司,CodeReview都是基本要求,代码合

做银行家里的数据专家:ING探索大数据时代下的金融最佳实践

大数据文摘出品记者:高延6月18-21日,O’ReillyAIConference在北京召开。大会上,来自荷兰的金融公司ING的IT主管BasGeerdink带来了《关于数字驱动企业》的主题分享。进入

项目管理最佳实践,企业如何进行有效的项目管理

前言:企业在划分项目时,可按照项目的复杂程度、管理范围等将项目分为三个级别,分别是企业级、部门级和小组级(与目标划分原则相同),然后将每一级的目标与项目对应起来。我们知道,企业制定的目标(OKR),一

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

宜信微服务任务调度平台建设实践|分享实录

导读:如今,无论是互联网应用还是企业级应用,都充斥着大量的批处理任务,常常需要一些任务调度系统帮助我们解决问题。随着微服务化架构的逐步演进,单体架构逐渐演变为分布式、微服务架构。内容来源:宜信技术学院

宜信开源|微服务任务调度平台SIA-TASK入手实践

引言最近宜信开源微服务任务调度平台SIA-TASK,SIA-TASK属于分布式的任务调度平台,使用起来简单方便,非常容易入手,部署搭建好SIA-TASK任务调度平台之后,编写TASK后配置JOB进行调

微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件,包括:

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

🚀 Hyperf 发布 v1.1.8 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 新增 #965新增RedisLua模块,用于管理Lua脚本; #1023hyperf/metric组件的Prometheus驱动新增CUSTOM_MODE模式; 修复 #1013修复Js

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象管

《PHP 微服务练兵》系列教程

本系列教程将从零开始使用PHP搭建微服务,涉及知识docker、mysql、Elasticsearch+Kibana日志分析系统、minio文件储存、阿里ACM配置中心、jenkens自动化测试部署、

微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:网络延迟。同步进程间通信导致可用性降低。 在服务之间维持数据一致

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对

基于JWT规范实现的认证微服务

本文由公众号EAWorld翻译发表,转载需注明出处。作者:MarceloFonseca译者:白小白 原题:Buildinganauthenticationmicro-servicewithJWTsta

微服务配置中心完全解读

本文作者:风卿,Nacos社区committer.在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力

可伸缩的微服务告警系统设计指南

Uber的软件架构由成千上万的微服务组成,有赖于此,我们的团队可以快速的自主迭代并支撑公司的全球扩张。这一架构支撑了大量的上层解决方案,如移动应用,内部基础设施服务,以及拥有复杂配置的产品,相关配置会