设计模式是软件开发中的重要经验总结，Gang of Four (GoF) 提出的经典设计模式则被誉为设计模式中的“圣经”。但是设计模式往往是以抽象和理论化的方式呈现，对于初学者或者没有太多实战经验的开发者来说，直接学习设计模式往往会显得枯燥乏味。 市面上或者网上也经常有一些书籍或者文章，尝试以实际的应用场景深入浅出地介绍设计模式。但是这些资料所列举的样例或应用实践，往往都是一些构造的虚拟场景，缺乏生产级软件的真实应用。而软件理论最重要的是学以致用，那是否有真实生产级代码的学习机会呢？ iLogtail 作为一款阿里云日志服务（SLS）团队自研的可观测数据采集器，目前已经在 Github 开源，其核心定位是帮助开发者构建统一的数据采集层。iLogtail 在多年的技术演进过程中，也一直在尝试进行各种设计模式的应用，这些设计模式的应用大大提升了软件的质量与可维护性。本文我们将结合 iLogtail 项目，从实践角度探讨一些常见设计模式的技术原理。在这里也要感谢字节跳动多位同学对 iLogtail Golang 部分架构的一些升级优化。
在我们对数据库技术方案设计的时候，我们是否有自己的设计理念或者原则，还是更多的依据自己的直觉去设计，是否曾经懊悔线上发生过的一次低级故障，可能稍微注意点就可以避免，是否想过怎么才能很好的避免，下面规范的价值正是我们工作的检查清单，需要我们不断从错误中积累有效经验来指导未来的工作。以下规范在大型互联网公司经过了充分的验证，尤其适用于并发量大、数据量大的业务场景。先介绍的是安全规范，因为安全无小事，很多公司都曾经因为自己的数据泄露导致用户的惨痛损失，所以将安全规范放到了第一位。
当代AI来势汹汹，本文从AI的特点、对研发的挑战、AI的应用工程和场景分化等剖析了AI时代的应用工程化架构演进之路。
我从2015年起至今2022年，在业务平台（结算、订购、资金）、集团财务平台（应收应付、账务核算、财资、财务分析、预算）、本地生活财务平台（发票、结算、预算、核算、稽核）所经历的业务系统研发实践的一个总结。 1.核心是面向复杂性业务支撑的实践经验（个人概念里的“复杂业务“，大概至少面向5类行业若干业务线且业态差异很大），文章不涉及性能、稳定性、资损防控、大数据离线研发，聚焦在线业务系统架构对多态业务的包容性、开放性、灵活性、可读性。 2.文章较多强调”个人”两字，因为仅是我个人在实践上归纳总结的一些方式方法。 3.实践经验主要来自两类，一类是接手旧系统，得以见识不一样的设计，文中“见过”特指。二类是自己新建的，之后又一而再三重构的，这类姿势下，人的反思记忆尤为深刻。
本文将分享一下个人的判断经验，期望引起大家对判断本身的关注。此外，由于决策常常是动态的，风格和经历也各有差异，也的确只能 “仅供参考”。
本文作者是蚂蚁集团客户端工程师博欢，介绍了支付宝如何基于 HarmonyOS 4.0 实况窗实现医疗场景履约智能提醒，欢迎查阅～
