大麦融入阿里电商平台，杰伦演唱会的票会不会好抢点？
2018年初，大麦决定将电商体系整体融入阿里电商平台，到目前大麦基于阿里共享电商平台体系的商品占比89%，交易占比超过90%，全部热门项目抢票已经在跑在这个链路上，在这个时间点来从技术角度回顾一下整个变迁的过程。
“星环”是阿里的共享平台接入不同业务方的产品技术体系，大麦的融入也正是基于星环的能力。
背景
首先来看下在项目启动之前的一些背景情况，主要是当时大麦交易所处的一个状态，已经我们为什么选择去做这件事情。
2017年底，大麦主交易流程已经迁移到阿里巴巴技术体系内，在交易核心链路上替换了大麦原有的技术体系，大大的提升了交易体系稳定性。上线后，交易方面以及大型抢票再也没有出现过比较大的问题了。但是从产品技术交易看依然存在很多问题：
若干依赖服务（尤其是商品、库存）依然在大麦机房，需要继续迁移；
交易容量问题，由于商品库存仍然大麦机房，库存扣减能力比较低，遇到周杰伦演唱会这样的大型抢票，有比较大的提升空间；
与阿里的共享电商体系互相独立，不利于未来的发展。
纵观上述几个问题，如果我们让大麦电商整体融入阿里共享电商技术体系，都会迎刃而解。尤其是第三个方面，面向未来，如何借力阿里巴巴的商业生态元素来发展，成为大麦战略上的重点。
我们一直相信，大麦电商体系融合到共享电商平台，是一个正确的发展方向。但是在最开始的阶段，大家还是有一些犹豫的。大麦有一些来自飞猪的产品技术同学。飞猪所承载的旅行业务同样是一个和淘宝、天猫差异很大的垂直电商。当时飞猪也没有融入到共享平台，可以看到原因肯定是多个方面，比如之前共享体系还没有足够好的开放能力来容纳差异很大的业务，其中一个典型的例子是，共享体系是不允许业务方随意外调服务的。
到2018年，共享交易已经逐步把平台和业务的边界逐步划分开来，建立了一套平台提供基础能力，业务自行扩展实现差异化逻辑的标准。经过实际调研看到这些进展之后，更加坚定了我们迈出融合这一步的信心。因此大麦正式启动了向阿里电商平台融合的项目，大麦交易进入一个全新的阶段，整个大麦电商体系也完全进入了一个新的纪元。
交易模块化框架TMF与星环
2.1 基于TMF的交易定制
在项目刚启动的时候，星环尚未完全就绪。大麦业务的差异化定制，主要还是基于交易模块化框架（TMF）在共享交易的各个应用中做定制来实现的。
TMF的逻辑是，一次请求来到交易，首先识别业务身份，搞明白是谁家的业务，然后在业务流程运行过程中，相应的业务能力扩展点被执行，达到差异化定制的目的。业务身份的识别标准往往会是商品、类目或者其上的一些属性。例如大麦的业务身份，对应的识别标准是，商品上有一个标。
基于TMF来定制，以交易下单服务buy2为例，我们需要实现一个扩展包，其中的主要内容是：
业务身份识别：大麦基于商品标来识别；
扩展点定制：例如大麦定制了资金流走即时到账。
buy2的大概结构是：
入口服务->业务流程（BPM）->业务活动->业务能力->能力扩展点。
大麦针对buy2的扩展包，就是针对上述能力扩展点的实现，请求经过业务身份识别确定是大麦业务后，大麦会走到这些相关的扩展点实现。
这里其实会埋下一个伏笔，就是在商品查询出来之前，其实是不知道业务身份的。这个会影响后面监控、问题排查等方面的一些做法。
2.2 星环与业务定制
星环是个很大的东西，涵盖了需求沟通机制、业务定制、容器化、质量保障多个方面。全面的只是还是要从星环的文档和与星环团队的沟通中获得。这里只是我们作为大麦一个业务方在使用过程中看到的一些侧面。
TMF框架本身的开放性，已经能够支撑业务方在共享的体系下实现自己的定制，对想要借力共享体系，但是又有一定差异的业务来说，是非常好的。而后面的星环继承和发展了这种开放性，在我看来主要针对以下几个问题：
TMF阶段，业务方需要给各个共享应用分别实现定制包；
因为上述原因，业务需要清楚的知道共享体系的内部结构；
整体运行在一套基础资源上面，不同业务互相之间影响产生的稳定性隐患。
市面上复杂的SAAS系统，背后的物理结构是非常复杂的，而使用者要定制一些逻辑的时候，是不需要理解其背后的物理结构的。星环在扩展方面也肩负着向这个方面演化的使命。在TMF时代电商体系每个应用都有一套扩展点，每个业务方需要的话都要为多个共享应用实现扩展包。星环抽象了一个叫做”商业能力“的层次出来，统一全部业务能力的扩展点，最终实现定制方基于一套扩展点来定制一个包，部署到共享各个系统中这样的效果。
具体来说，例如”基础交易“是一个商业能力，它的定制点，包含了商品、交易多个方面，很多扩展点。涉及多个共享应用。商业能力扩展点这一层，包含了上述多个方面的扩展点，业务方通过这个统一的层次提供的语义来扩展，而在其背后，星环的实现层会把原始的业务能力的扩展点，桥接到星环商业能力的扩展点上来。
容器化与发布流程
星环里面一个重要的事情是容器化。按照星环网站上的说法，目标是四个：
业务自治:业务方独自完成业务的设计开发、测试和部署运行；
业务隔离:业务与&业务/业务&平台隔离再不担心业务变更互相影响；
业务动态部署:业务方可以在线进行发布和部署，快速响应业务需求；
业务快速恢复:业务应用发布上线平台保留历史版本，可在线版本回退。
这个事情涉及从系统逻辑结构，到发布方式的一系列变化。从这些变化里面可以了解到”容器“究竟是什么。
3.1 ClassLoader隔离
阿里共享业务平台的应用以交易下单服务为例，作为一个大容器，业务方例如大麦的定制包作为一个子应用，就是一个子容器。每一个子容器都有自己独立的ClassLoader。这个classLoader以平台的ClassLoader为parentClassLoader，同时，自己内部基于配置知晓自己这个业务APP的jar包在哪里。
我们知道Tomcat作为一个容器是违背了双亲委派模型的，优先加载应用的类，从而实现WEB-INF/lib以及WEB-INF/classes类的优先级更高，而星环的容器没有这样做，依然是原本的双亲委派模型。这样做的结果是：
对于平台已经存在的类，会使用平台公共的实例；
对于仅存在于业务APP包中的类，平台层找不到，所以会加载业务APP中的类。
这个方式有优有劣。优点在于尽可能的共用了平台层面所能提供的类定义，可以控制metaspace的大小。在另外一个方向上，阿里中间件的Pandora隔离容器使用类似tomcat的机制以插件的class优先，从而做到各插件类路径隔离，从2017年开始要求metaSpace要配置512M了。而且，星环容器所承载的业务方子容器量会远超过Pandora所加载的插件量，如果不做这个控制，诸如commons.lang下面的类也是一个容器一份，MetaSpace要的内存简直无法接受。
上述优势从另外一个角度看恰好又成了一个潜在的威胁。各方APP所以依赖的一些公共的三方包，甚至公司内部提供的二方包，具体在系统启动起来之后使用的版本，是有互相影响的。两个APP使用了相同的三方包的场景下，实际上最终平台是按照maven的就近原则来打包其中一个到war中，于是实际过程中，一个APP升级该三方包，也就影响到了另外一个APP。实际上导致容器隔离不彻底。当然，这只是一个权衡。实际上如果真完全以Pandora模式，又会出现平台export哪些类给到业务APP的细节问题。
3.2 独立的Spring子容器
Spring的容器也做了类似上述结构的父子关系，不用担心各个APP内的bean之间的冲突。一个结果是，子容器里面仅包含业务APP中所定义的bean。那么，类似限流、降级这样的平台层自动代理的一些事情，在子容器里面是没有的。如果你的业务APP希望使用到限流、降级，那么你需要在业务APP的spring文件中引入相关的bean定义。
3.3 自主热发布
共享应用由于结构、业务及其复杂，发布一次的时间，非常长，这是一个极其痛苦的过程。以交易下单服务为例，一次构建几分钟，一次部署要10几分钟到半个小时的时间。相比于业务方自己的小应用一次构建加部署5分钟以内，这个时间的确是太长了。
基于classLoader隔离和Spring子容器，整个业务APP的热发布成为可能。所谓热发布就是在不停tomcat的情况下，把一个业务的变更发布到线上。一次热发布过程大约如下：
应用offline 当然要首先让流量不再进来；
下载更新应用的jar包，这个过程使用了目标应用的主干配置项来替换jar包中的引用；
容器销毁-重建，过程中抛弃了原有的classLoader和spring子容器，创建了新的实例；
应用online。
热发布大大缩短了业务构建部署的时间，基本上一次构建部署5分钟内搞定。相比之前每次war部署，幸福的像是回到了伊甸园。
实际上平台一次war发布经常需要几个小时的时间，这其中固然有分批的因素，但是本身应用构建、启动慢也是一个重要的原因。从稳定行方面来讲，线上发现一个问题，如果改代码、war发布，这样的时间加起来几乎足以似的问题变成故障，小故障升级成大故障。有了热发布，腰不酸了，腿不疼了，轻轻松松搞定发布。线上问题发现到改动、恢复时间也大大缩短。
但是热发布的逐步完善过程还是很快的，最初有一些限制，后来都逐步优化掉了：
静态配置项变化，不能热发布。目前已经使用了对应变更的配置项得以解决；
依赖包变化不能热发布。这个事情曾经想过用fatjar来解决，后来已经支持附属jar发布，大麦已经在使用；
前端交互协议组件奥创的修改不能热发布。这个事情使用新奥创得以解决，大麦19年完成了切换。
热发布上线后，大麦不能热发的场景，大多数是奥创改动和依赖包改动。现在正在解决依赖包的问题。
目前，业务定制改动后，发布的时候还是要勾选一下要发布的目标系统，例如buy2。未来的方向应该是业务方不用关心改动发布到共享的什么系统里面去。
3.4 独立分组与环境隔离
大麦在buy2上划分了独立分组。后面飞猪等业务方也都是用了独立分组。星环目前采用中间件提供的环境隔离方案把业务方的流量隔离到目标独立分组。
首先buy2给大麦划分了一个独立机器分组叫做buy2_damai_host。
然后，大麦的流量通过三种方式路由到大麦独立分组：
nginx路由，部分流量在公共分组的nginx层可以识别到url参数或者Header，然后走到buy2_damai_host的Java；
Java兜底路由，部分流量只能在buy2host这个机器分组里面把商品查出来之后，才能识别到是大麦的业务，此时再通过一次RPC调用，走到大麦分组；
RPC调用路由，大麦自己的Java应用在调用buy2的RPC服务之前，可以通过设置路由相关的鹰眼标来指定调用到大麦分组。
大麦最初采用独立分组是基于物理隔离和降低运维成本的考虑。发展到现在，独立分组这个事情主要看到以下几个点（包括优势和问题）：
优势一：独立分组让大麦只关心自己分组的机器，在遇到某些问题的时候，处理起来比较方便。共享应用动辄几千台机器，查个问题需要好久。但是，独立分组大麦也就100多个机器，查问题成本完全不是一个水位。
优势二：独立分组让大麦的监控可以只关心大麦分组，这个事情详细在下一小节来描述。
优势三：独立分组带来的物理隔离，让大麦在自己的分组上开启一些特殊的能力不用担心影响别的业务方，具体参考下面的问题排查小节。
优势四：独立分组在平台整体war发布的时候，可以自主控制发布节奏。一般来说平台整体的发布因为应用众多，所以分批较多，而且间隔也经常拉的很长，经常跨天。一些需要快速生效的问题修复场景，这个过程慢的让人捉急。独立分组对应在应用发布平台上是一个独立的环境，发布单也是独立的，因而可以在保障稳定的前提下继续发布，提高发布效率。
同时独立分组也带来一些困扰，这也是目前大麦和共享同学还在想办法优化的一些事情：
一方面，共享的应用都是单元化的，这个独立分组也要保障多个单元的容量，在单元化流量调整的一些场景下，需要密切的做好沟通，避免特定单元容量不足引发问题。
另外一方面，独立分组还是带来了一定的资源浪费。大麦业务的流量有个特点是大型抢票来的时候（每周几次）流量瞬间很高，而无大型抢票的时候流量低的不好意思说。为了维持大抢容量，独立分组必须有足够的资源配置。
目前大麦仅在buy2上做了独立分组，其他几个应用都还没有做。飞猪和新零售做的多一些。
监控
监控部分，说三个方面：
4.1 系统监控
系统监控说的是cpu、load、网络这些方面。对于做了独立分组的应用，可以在监控平台上针对这个分组配置一个虚拟应用，看起来和其他应用没什么区别，看起来很方便。如果没有独立分组，那么系统监控这个事情，基本上就只能是平台层面关注了。
4.2 业务监控
共享的主要应用都会有统一的业务监控以及对应的大盘。但是这些大盘的视角都是平台视角，大麦这样一个小业务放在里面，典型的效果就是下单全部失败，成功率曲线也看不出来明显的下跌。
所以必须做业务线视角的监控和大盘。因而大麦参考共享的监控大盘配置了自己的业务监控。包括渲染量、下单量以及相关的成功率、错误码等方面。
这里面有一个日志数据筛选的事情也经历了一些变化过程。早期，大麦是在日志里面过滤有大麦业务身份的数据，然后基于过滤出的日志内容做监控。后来发现，对于走到业务身份识别逻辑之前就报错了的请求，在这些日志里面是不可能有业务身份数据的。所以就修改成了拿buy2_damai_host上的所有数据来做监控。正好环境隔离方案上线后，大麦分组不再会有别的业务的流量，所以这样做是完备的。
可以看出来，上述逻辑严重依赖独立分组。没有独立分组的业务或者应用，会存在一个问题，代码走到业务身份识别之前出现的问题，是很难做到业务方独立的监控里面的。
另外一个实践是，对于大麦这样一个小业务，平时的请求量非常低。以渲染为例，平时1分钟也就几十个请求。渲染失败的原因里面，类似库存不足、超过限购数量、相同身份证已经购买过之类的这样的原因，如果都作为请求失败来看的话，成功率的曲线会很难看。基本上跌的很多，真正的线上问题会被淹没。所以大麦在GOC监控里面，会把类似库存不足这样的错误码排除出去，从而做到一个基本上维持100%成功率的曲线。
这样做能够达到根据这个曲线更加准确的判断系统运行状况。这不是一个完备的方案，但是实践下来证明是有效的。
4.3 异常监控
一个应用的异常堆栈日志是应用是否正常的重要表征。有新的异常出现或者某类异常大量飙升的时候，基本上可以判断有问题了。一个好的实践是，系统异常打堆栈，业务异常（例如库存不足）不打堆栈，这样能够让应用的异常量维持一个比较低的水平。大麦技术团队经常会使用鹰眼团队提供的监控产品来看共享应用的异常信息。根据某一类型的异常突增这样的信息来分析判断问题。
问题排查工具
技术团队的工作里面，线上杂七杂八的问题的排查工作，一直以来都是重要的组成部分，而通过工具建设来提升问题排查效率也是技术团队一直追求的事情。这个方面大麦以往有一些实践，融入共享之后也在共享的体系下共建了一些能力，这里分享出来。
这里描述的“问题”，一般是指两个方面，一个是用户或者客服、业务同学反馈过来的一些问题场景。例如某某用户具有购买资格但是下单提示不能购买，或者某某订单没有用到一个优惠。另外一个方面是业务监控发现的，例如某一类错误码突增。
问题排查过程要基于已知的这些少量的信息，去追踪还原当时的场景。典型的想法是去机器上找日志。但是这种方式效率比较低，而且会把这个工作局限在技术人员身上，无法给到上层。
阿里的鹰眼的业务日志是一个很好的工具，现在大家也经常可以拿着订单号、traceId来查询一些链路上的日志。但是会有一些局限：一来，没有订单号的场景，例如订单确认页打开失败，这种无从查起；二来，很多时候是没有traceId的……
大麦技术团队和阿里共享团队协同建立了一个基于业务日志的问题排查工具，做到基于业务自己的场景打印相关日志，并指定自定义的索引字段来应对问题排查时候的查询。
5.1 效果
我们做到可以根据一个错误码，查询这个错误码产生的链路日志（利器），根据某一次请求失败的日志详情来判断问题的具体原因。可供查询的日志数据里面实际上包含了3个部分的日志：
A. 交易下单应用的入口服务和依赖服务的拦截日志；
B. 交易下单应用的入口异常日志；
C. 业务扩展包中自主打的一些日志。
业务APP可以自主打印一些指定格式的日志。日志内容、索引都是自定义的。配
置采集之后即可在一个统一的页面上查询。
5.2 怎么实现的
上述日志最终都是通过一个通用的二方包打到磁盘上，然后通过日志采集服务采集投递到了阿里云的日志服务SLS里面（需要各业务方自己提供LogStore，并承担成本）。然后基于SLS的能力提供查询。
5.3 更进一步
大麦基于上述日志，做了一层格式化和语义转换，把技术人员才能看懂的信息，转换成为非技术同学也能看懂的说法，从而把一部分问题的排查交给了上层的非技术同学。
尾声
大麦通过把整个电商融入阿里共享电商平台，稳定性、性能上都得到了大幅的提升。在产品能力上也自然而然的可以低成本的借助阿里的各种基础设施，在这个基础上，大麦的业务也在逐步发展。过程中有很多抉择、取舍，这篇文章也是希望从技术过程的角度尝试对一个小业务如何融入大平台做一个分享，希望有类似场景读者，不论是做平台还是做业务，能够有所收获。
即日起至 3月21日，千万流量支持原创作者，更有专属【勋章】等你来挑战
☞Javascript函数之深入浅出递归思想，附案例与代码！
☞不看就亏系列！这里有完整的 Hadoop 集群搭建教程，和最易懂的 Hadoop 概念！| 附代码