总结了雪球在建设规则引擎过程中的探索和实践过程，推出对业务人员非常友好的可视化的策略编排功能，在使用上接近sql条件的编写，在研发方面，缩短了开发时间，只需要关注动作与特征开发。

介绍了今年雪球大前端团队在三端同构建设上的实践，包括RN / H5 同构的能力及效果、样式组件系统的优势及定制实现、同构的改造及服务端渲染 SSR、同构的 CICD、单元测试及开发测试流程、同构的 D2C 代码智能生成等。

随着移动互联网的迅猛发展，目前市面上「端」的形态多种多样，Web、App 、车载、微信小程序等各种端大行其道，同一个业务需求往往又需要在多端上去实现，针对不同端去编写多套代码的成本显然非常高。近年来「跨端」是前端界比较流行的一个词汇，不论是国内还是国外，跨端技术百家争鸣，方案频出。

Apache APISIX能极大地简化双活架构的实施复杂度，本文总结描述了 Apache APISIX 助力雪球双活架构演进，为雪球未来云原生架构演进打下了良好的基础。

随着公司业务的不断发展，不同业务线数据都有了大规模积累。在此基础上为了精细化运营，更好地服务客户，就需要通过积累的数据沉淀出各类实体标签，比如用户标签、帖子标签、基金标签。

在苹果新推出的iPhone13 Pro和Max上支持了ProMotion，最大刷新率达到 120Hz，这使得用户对页面流畅性导致的刷新率变化更为敏感。本文总结了雪球 iOS 客户端在社区业务中 feed 流页面和正文页流畅性优化方面的工作。

怎么知道 Redis 里到底存了啥？都有那些 Key？每个 Key 用了多少空间？这些问题可以轻松得到解决 ...

雪球旗下的蛋卷基金交易系统是如何从无到有、从使用第三方到使用自研系统、从功能单一到功能丰富的？其中经历了一系列的改造、升级、重构，这次给大家分享蛋卷基金交易系统的演进过程。

天下武功，唯快不破，雪球数据中台AIBO，可快速集成雪球全业务数据(通用或定制方式)，通过模块化通用功能，灵活满足各业务线对数据分析和处理的需求，高效支持业务对数据的需求。

本篇文章将介绍我们在雪球行情图项目中，实际应用到的 canvas 性能优化方案，希望对大家有所帮助。

雪球统一推送平台，为社区和用户之间提供了一座桥梁：广泛覆盖、及时触达、精准投递。

而随着社区与基金、股票等业务的进一步融合，管理层以及各业务方对数据的准确性、及时性等要求进一步提高，业务的发展壮大也使得数仓规模越来越大。雪球大数据团队在支持现有数据需求的同时，也对历史沉积的数据做了梳理和优化。

对于正文页的对齐方式和排版，主流 app 为兼容长字符的英文单词和数字在两端对齐情况下可能产生的间隙过大的问题， 采用了左对齐 + 单词不截断的排版方式。

雪球最早也采用了这种左对齐的排版方式，但这带来了一个问题“右侧显示层次不齐，左侧视觉偏重”。在中文语境下，两端对齐左右对仗工整，两侧不会有多余空隙，可以保证段落的整齐划一，成规整的块状，相比左对齐阅读体验更佳，更舒适，为此雪球演进为两端对齐。

采用两端对齐后，由于单词仍是不截断完整展示，对于较长字符的英文单词/数字，就会出现字符空隙过大的情况。这就产生了一个技术上的取舍问题：单词不截断 还是 两端对齐 ？

大家可能会想到，如果像微信公众号把排版的编辑权限完全开放给用户（用户主导文章的对齐方式、单词的截断规则、页面的排版细节），文章完全交由用户控制，就不会出现细节上不可控的情况。伴随着文章排版控制权的转移，原本属于开发侧的工作也转移给了用户。这种实现方式并非一劳永逸的按钮式设置操作，由于每篇文章内容全然不同，必须因文制宜，用户需要对每篇即将发表的文章进行排版的设置。这看似完美的解决了排版问题，但从大多数雪球非专职运营的创作者角度来看，这无形中从“为”用户配置转变成了“让”用户配置，提高了创作门槛，增加了创作成本。

那有没有既保证了符合视觉审美的阅读体验，又能使用户无感知无操作完全从开发层面解决排版问题，又可以兼容长字符英文和数字的最优方案呢？

本文根据唐福林老师在“高可用架构”微信群所做的《股市风暴下的雪球架构改造经验分享》整理而成，转发请注明出处。