在容器化部署成为主流的现在，降低集群中单个容器的资源需求的意义已经不只限于更少的硬件成本，同时也意味着整个集群更加轻量化，这通常会带来一系列其他优势：例如更短的恢复时间，更精确的资源控制和调度，和更快速的伸缩和部署等。但在另一方面，一味的追求压缩容器配置必然会严重影响应用在稳定性、响应耗时和吞吐量等方面的表现，所以轻量化的措施需要在多个性能维度上进行仔细的权衡取舍，以达到一个总体更优的结果。

筛选已经成为各类网站的必备功能，也是用户使用最多的功能之一。

很多设计师在设计应用图标时都会遇到这些问题：比如切图需要提供哪些尺寸？图标切图要不要带圆角？提供了切图给到开发后为何系统会报错？开发说的自适应图标又是什么？...如果你对以上问题感到困惑，那么看这篇就够了。

相信每一位UI设计师都遇到过设计稿精美、高大上，但开发还原出的效果直接从卖家秀变为了买家秀。为什么总会遇到这样的情况，我们如何解决开发还原度低的难题？

Lottie入门指南，了解 Lottie 的优势，合理闭坑，安全食用！

在软件开发过程中，团队协作效率的提高是我们共同关注的问题。为了解决这一问题，许多团队都开始使用智能化工具。Design2Code（简称D2C）工具是其中一种广受欢迎的选择。

在本文中，我们将分享D2C工具的核心算法方案设计和实现过程，以及一系列的解决方案。无论你是开发人员，还是设计师，本文都将为你提供有价值的信息。我们希望，通过阅读本文，能帮助你更好地了解D2C工具，并在实际工作中发挥出最大的价值。

本文将会以Trip.com东南亚市场为例，阐述IBU设计师是如何对国际市场本地化的设计从探索、研究，并且将调研结论应用到东南亚市场的营销视觉设计当中的全过程。

携程商旅大前端的SSR探索之路。

Taro-CRN为后续携程的跨端开发生态打下基础。

我们在一个中间层的应用中使用了Servlet 3.0新增的异步特性。期望能提高应用的并发处理能力。

在互联网时代，每天都会产生海量的数据，去哪儿网成立至今，积累了海量的用户出行数据，每一次旅行机票记录，酒店记录，门票记录等等，这些数据都存储到数据库中，现在流行的 Mysql 数据库，一般情况下单表容量在 1kw 以下是最佳状态，如果将所有的历史记录都存储到 DB 中，那么每张表的大小将超过 10 亿级，根据不同维度的查询将是一个梦魇，比如通过订单号查询，根据用户加状态查询等等，数据库将不堪重负，慢查询可能导致整个库不可提供服务。常用的解决方案是把这些数据存储到一个备用的数据库或者异构的数据结构中，来提升我们的查询效率。数据同步系统就是做这件事的，将数据从一个数据源导入另外一个数据源，提供同构或者异构、低延迟的的数据的同步，提供高可用的数据同步服务，并且保证数据最终一致性。

1）携程酒店每天有上千表，累计十多亿数据更新，如何保证数据更新过程中生产应用高可用；

2）每天有将近百万次数据查询请求，用户可以从粗粒度国家省份城市汇总不断下钻到酒店，房型粒度的数据，我们往往无法对海量的明细数据做进一步层次的预聚合，大量的关键业务数据都是好几亿数据关联权限，关联基础信息，根据用户场景获取不同维度的汇总数据；

3）为了让用户无论在app端还是pc端查询数据提供秒出的效果，我们需要不断的探索，研究找到最合适的技术框架。

对此，我们尝试过关系型数据库，但千万级表关联数据库基本上不太可能做到秒出，考虑过Sharding，但数据量大，各种成本都很高。热数据存储到ElasticSearch，但无法跨索引关联，导致不得不做宽表，因为权限，酒店信息会变，所以每次要刷全量数据，不适用于大表更新，维护成本也很高。Redis键值对存储无法做到实时汇总，也测试过Presto，GreenPlum，kylin，真正让我们停下来深入研究，不断的扩展使用场景的是ClickHouse。

基础数据的维护对于提升测试效率是很重要的一个环节，这里介绍一种数据库表粒度的数据同步方法来实现测试环境基础数据的维护。

这篇文章可能跟Anroid的关系不是很深，主要介绍Groovy是如何一步步解析Android的DSL语言，这样你在配置一些gradle文件的时候可以更加得心应手。

在性能方面，Flutter的表现比RN更为优秀。

分布式数据库OceanBase在携程的实践之路。