现在才发现，离我上一篇博文竟然接近1年没有发过东西了。惊呆了我。我要每周都写了，就算不写技术也要写其他东西，不然真的是思考的多，没有留下记录都是空白。
在携程商旅主要做酒店直连这一块。商旅酒店其实架构都很老，并且实践的技术很多不是很新。但是抗住了之前的压力，但是开始做直连之后就显得比较不行了。
之前商旅的酒店类型区分为如下
1.OTA酒店2.单体酒店3.非直连套系酒店4.直连套系酒店
区别
1.就是依靠OTA，做分销，2.合同酒店然后维护，未来还是靠直连。3.非直连套系酒店4.直连套系酒店，靠直连
这里面一些因为商旅的业务特点，我就不展开了，有机会再写。我们直接看直连，如下图
服务都是分为了两个模型，也就是一个拉，一个推。来作为模型。
简单来说，直连平台，就是将多个平台连接起来。并没有什么特殊的。一个个项目堆下来总能解决的。
但是从架构上，会逐渐臃肿，直到难以接受的程度，因为接入的直连虽然现在表现很好，但是随着需求的演进，项目堆下来的方案，是肯定不能接受的。所以要建立平台。实现通用方案。
业务上简单说就是
要自动化，尽量快速接入，方便扩展，可靠性足够
建构简单的步骤
我们之前首先做了数据库分库分表。来将国内大的酒店集团全部建立为单独的表。小的酒店就会合并，减少分表。推模型中，我们做了临时库，将临时库同步到正式库。
这是一个简单的数据库架构。其实里面做了很多优化，因为有很多指标。
我一直在考虑使用KAFKA/QMQ等消息队列来解决并发推送的问题。但是因为我们分库采用的是按hotelID进行分库，然后如果采用消息队列的话，会造成数据无法一批批处理，造成数据库查询利用率过低。
但是当时一个是架构是已经架构了，可以用，其实现在也可以用，但是指标不好看。
这里也是其实在当时太怂，刚进公司觉得自己水平不够，不敢坚持自己想法。
现在我将短期价格缓存，然后很多一些冷数据都直接缓存化。
然后做数据压缩，结构优化。来保持数据库 以及处理性能时间等指标保持平稳。
这就是商旅之前直连平台的简单介绍。
现在优化的一个沉入代码层面，之前很多项目代码，抽成了common jar包。以后逐渐抽成服务。
其实这里jar包和微服务化，和领导有过讨论。
jar包优势
1.jar包不存在性能问题，服务可能存在
jar包劣势
1.jar包存在管理困难，版本更新困难问题‘’
虽然我不认为劣势是可以接受的。但是最终团队都认可了jar包方案。不过也是当时自己刚进公司，没有坚持导致的。现在如果我坚持我认为是可以通过的。这也是学习的一部分。
下次再画技术架构图。
