领域驱动设计作为一种设计思维方式从被提出到现在，社区也不断丰富了领域事件，事件溯源，CQRS等设计元模型。随着个人对领域驱动设计的理解不断深入，结合自身在项目中的实践经验，以目前bilibili OGV的业务为例通过领域驱动设计的分析设计建模方法，试图说明领域驱动设计的统一过程和思考方式，本篇文章只包含问题域分析，没有提及架构，设计模型和编码层面的内容。文章通过对价值需求分析方法，获取问题领域相关利益者，在相关利益者的基础上通过分析业务需求的业务流程和业务场景，在业务需求分析结果的业务流程图和业务用例图基础上，通过领域识别和划分得出领域划分结果领域映射图让问题领域变的清晰。
最近AIGC的爆发引发了非常多行业的恐慌也包括程序员群体。如何掌握工具例如Copilot等是下一个时代最重要的能力。但是在当前苹果封闭的生态下，对于先进的生产力的渴望也是促使这篇文章诞生的原因。 Xcode是苹果的用于研发苹果软件生态的集成研发环境（IDE）相信作为苹果最强生态的iOS研发应该完全不陌生。这个让人又熟悉又陌生的老兄弟跟着iOS的辉煌也已经快20岁了，笔者差不多是从3.x年代开始使用Xcode研发iOS 3.x的而这15年唯一不变的可能就是在商店里糟糕的评分和社区中不怎么好的口碑。
负责B站数据中心网络规划、设计、建设、运维与优化，为公司业务提供稳定且可靠的网络服务。整个团队专注于数据中心内外网、骨干网络、负载均衡、传输网络、虚拟化网络以及国际化网络的落地和应用，并根据业务的发展需求不断迭代更新底层基础网络设施。
2023年4月26日是第23个世界知识产权日，每年4月20日-4月26日是全国知识产权宣传周。 在这期间，哔哩哔哩公司内部发起了2023年度哔哩哔哩技术专利投票活动。最终根据票选结果决出10个优秀技术专利。 我们希望可以通过本次活动加强B站同学对于知识产权的认知和投入，同样B站也会在中国向知识产权强国迈进的征程中，勇担使命，发掘潜能，创造不凡。
当前站内存在一定比例的UP主投稿重复、低编辑度的低创视频投稿的情况。低编辑度重复投稿表现为，相同或不同视频作者对同一视频素材进行黑边、裁剪、渣清、模板、录屏、变形、滤镜、模糊填充等不影响内容实质的编辑后进行反复投稿
随着云原生技术的普及，其暴露出来的攻击面也被黑客们念念不忘，相关的攻击技术也跟着被“普及”，自动化漏洞利用攻击工具更是如雨后春笋般出现在GitHub开源平台，其中比较有代表性的如cdk-team/CDK。其是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。 在漏洞利用门槛如此低廉的今天，作为企业安全的建设者（搬砖人），除了考虑部署容器层面运行时检测平台，在k8s api-server层面，启用日志审计功能，也是一个成本低廉又高效发现入侵攻击的途径。 通过对api-server的日志进行审计分析，对于攻击者的信息收集行为，部署k8s cronjob后门、利用rbac做权限提升等持久化攻击行为都能及时的发现并输出告警。
随着弹幕数量越来越多，以及我们会不断的往视频上面添加越来越多的动画，如何让各种弹幕流畅的展示给我们的用户，成为了我们必须要考虑的问题。这要求我们需要了解浏览器底层的渲染原理，才能以最低的性能消耗来实现我们的各种弹幕效果，知道哪些性能消耗是我们前端可以避免的。
在数仓分层架构体系中，从 ODS层到 DWD层数据转换需要进行数据清洗、脱敏、列式压缩等步骤。在B站用户行为埋点数据 ODS到 DWD层转换过程中，为了解决日增千亿条、20+TB/天增量规模下数据重复摄取带来的资源严重消耗的问题，引入了北极星（B站用户埋点行为分析链路）分流，按照部门进行分表。在埋点设计中使用spmid模型，将事件类型拆分为浏览 pv、曝光 show、点击 click等多个事件类型，并以这些事件类型作为除天、小时分区以外的第三级分区，再以事件类型产品来源作为四级分区。通过基于部门业务区分按照埋点事件类型+产品来源以多表多分区控制的形式，最大程度降低下游任务文件数据摄取数量以减少资源消耗。
众所周知，B站是个学习的网站，网页端和粉版移动端都非常的好用，不过，相对其它平台来说B站的PC客户端也算是大器晚成了。在有些场景PC客户端的优势也是显而易见的，比如，跓留电脑桌面的快捷、独立的应用窗口、特有的交互方式等，因此就有了很多喜欢B站的技术大佬整出了不少体验不错的第三方PC应用，比如云之幻版、逍遥橙子版等。 当然我站也有一个源自三方的UWP客户端，但是由于历史原因一直没有得到很好的维护，在21年底，一个需要在电脑端预装的需求让我们有了开发一个全新的PC客户端的想法。
为什么使用多云： 公有云因为其弹性、按需使用以及多地域的覆盖等优势，企业在高速发展的过程中往往会选择公有云来提供应用所需的基础设施； 为了高稳定性和成本最优的考虑，一般会引入多家云厂商； 多云部署防止单一云厂商故障导致服务完全不可用； 采用多云也提升了采购上的议价能力，避免单一厂商绑定，在价格谈判中处于劣势； 不同的云厂商在覆盖的地域、产品的能力上不一致，引入多云可以充分发挥各厂商的服务能力和产品优势。 多云带来的问题： 公司内因为云上资源使用的业务比较多，资源新增和交付主要依赖人工沟通并在控制台上进行操作，效率很低，在遇到大批量的资源交付服务器、数据库和负载均衡等多产品联合交付等场景的时候，无法满足业务的高速迭代需求； 不同的业务使用的云产品不同，基本上都涵盖了主要的IaaS和PaaS类的云产品，资源分布在多个公有云、多个云账号下，无法准确掌握全部资源情况，寻找资源困难，难以区分哪个资源由哪个业务使用； 用户在公有云控制台上权限混乱缺乏管理，存在权限泄露问题，操作不同资源需要通过密码登录不同公有云不同账号，难以批量操作，高危操作缺乏审批流程；
