EmmanuelAdesina/emmanueladeshina

# Adeshina Emmanuel Abiodun 后端、平台与安全工程师 — 尼日利亚 [GitHub](https://github.com/emmanueladesina) · [Hashnode](https://hashnode.com/@emmanueladeshina01) · [邮箱](mailto:E.adeshina@proton.me) 我构建后端和平台系统的前提是：总会有某些东西最终发生故障——一个节点、一次网络分区、一个依赖项，或者一个拥有过多权限的运维人员。我的工作领域是分布式系统、事件驱动架构和基础设施安全：这是位于应用之下的那一层，决定了故障是被隔离还是演变成灾难。我创立了 **RELIASTRA**，这是一个围绕不可变审计链和 Kubernetes 原生基础设施构建的金融负债智能平台；同时，我正在开发 **CHIMERA**，一个用于协调自主 AI agent 的操作系统。大部分工作发生在功能上线之前——对故障路径进行建模、定义服务边界，并决定当系统出现问题时应该作何反应。 ## 工程哲学 我不会从框架或编程语言开始设计。我从故障模式开始：当下游服务变慢时会怎样？当一条消息被投递两次时会怎样？当部署进行到一半失败时会怎样？当运维人员拥有超出任务所需的权限时又会怎样？服务边界、一致性模型、审计策略和部署拓扑结构，都是将故障分析和攻击路径建模作为设计输入来决定的——而不是在架构已经固定之后才进行的评审。 以下几点由此衍生： - 分布式系统被设计为环境，而不仅仅是代码——网络默认是不可靠的，架构必须能够在不可靠的网络中生存。 - 状态变更或审计路径，在设计时首先要保证不可变且抗竞态条件，然后才会考虑速度。 - 基础设施策略——速率限制、隔离边界、访问控制——是源自建模后的攻击路径推导出来的，而不是事后作为检查清单来应用的。 - 无法被观测的系统不值得信任。对故障状态的可视化是设计的一部分，而不是在出现故障后才添加的工具。 ## 我正在构建的项目 ### RELIASTRA — 金融负债智能平台 **创始人兼首席后端工程师** RELIASTRA 是一个用于金融负债智能的生产级平台，被设计为一个以不可变审计为核心的事件驱动系统。它由 **TrustMonitor** 演化而来，这是一个早期企业监控平台，在被作为 RELIASTRA 后端的基础之前，已经扩展到了 826 个以上的生产 API endpoint。 **架构亮点** - 从零开始构建的事件驱动微服务架构 - 不可变审计链，防范竞态条件和完整性故障 - Guardian 驱动的基础设施策略——访问和基础设施规则在实施前，通过故障分析和攻击路径建模推导得出 - 分布式锁、背压控制和 Redis Bloom filter，用于负载和重复控制 - 优雅的连接 draining 和服务隔离，作为首要的部署考量 - Kubernetes 原生部署：可扩展性、高可用性和灾难恢复是设计之初就内置的，而非后期改造的

高层请求与事件流

``` flowchart LR Client -->|HTTPS| Kong[Kong API Gateway] Kong --> SvcA[Liability Service] Kong --> SvcB[Audit Service] Kong --> SvcC[Risk Engine] SvcA --> Kafka[(Kafka Event Bus)] SvcB --> Kafka SvcC --> Kafka Kafka --> Chain[Immutable Audit Chain] SvcA --> PG[(PostgreSQL)] SvcA --> Redis[(Redis / Bloom Filters)] Chain --> PG subgraph Cluster[Kubernetes Cluster] Kong SvcA SvcB SvcC end ```

**技术栈：** Go · Python · Kubernetes · Docker · PostgreSQL · Kafka · Redis · Kong Gateway · Terraform · AWS ### CHIMERA — 智能操作系统 **创始人兼首席系统架构师** CHIMERA 是一个用于协调自主 AI agent 的平台——包含记忆、规划、推理和编排，它是作为后端基础设施构建的，而不是在模型之上叠加的应用逻辑。 **架构亮点** - 用于协调多个自主 agent 的模块化编排架构 - 为支持自主执行而构建的后端基础设施，而不仅仅是单轮推理 - 超前于工作负载设计的可扩展平台服务 - 基础设施优先设计：在构建其上的应用之前，先构建平台

概念层模型

``` flowchart TB Agents[Autonomous Agents] --> Orchestration[Orchestration & Planning Layer] Orchestration --> Memory[Memory Layer] Orchestration --> Reasoning[Reasoning Layer] Orchestration --> Execution[Execution & Tooling Layer] Memory --> Infra[Platform Infrastructure] Reasoning --> Infra Execution --> Infra Infra --> Automation[Enterprise Automation] Infra --> SecIntel[Cybersecurity Intelligence] ```

## 兴趣领域 - **平台工程** — 应用代码与基础设施之间的操作层面：服务边界、部署拓扑、故障隔离。 - **云安全** — 从攻击路径建模推导出的访问控制和基础设施策略，特别是围绕 IAM 的部分。 - **分布式系统** — 跨服务和节点的一致性、排序和故障处理。 - **AI 基础设施** — 自主 agent 之下的平台层：记忆、编排、执行——而不是模型本身。 - **生产可靠性** — 面向降级运行的设计，而不是仅仅为理想路径做设计。 - **后端架构** — 将服务边界和数据所有权视为架构决策，而非实现细节。 ## 技术研究 在 [hashnode.com/@emmanueladeshina01](https://hashnode.com/@emmanueladeshina01) 上的技术写作，涵盖 AWS IAM、云安全、分布式系统、生产工程和后端架构。 其中一篇文章将 AWS IAM 建模为关系图，而不是扁平的权限列表——将其视为一个攻击路径分析问题，而不仅仅是身份验证问题。 ## 精选工程原则 - **为故障而设计。** 假定每个依赖项都会发生故障；架构定义了当故障发生时系统应作何反应。 - **基础设施优先于功能。** 在依赖于部署拓扑、隔离边界和故障恢复的功能开发之前，先完成这些基础设施的设计。 - **通过架构实现安全。** 访问控制和基础设施策略源自建模的攻击路径，而不是上线后应用的检查清单。 - **可观测的系统。** 无法被看到的故障状态就无法被诊断——可视化是设计的一部分。 - **确定性的部署。** 部署在 staging 环境中的行为应与在 production 环境中完全一致，每次皆是如此。 - **操作简单性。** 复杂性的合理性在于它能预防的故障模式，而不是因为它使问题更容易被描述。 ## 技术 **编程语言**    **框架**    **数据与消息**    **基础设施与编排**       **网关**  **自动化**   **安全**   ## 当前重点 - 扩展 CHIMERA 的编排层，以支持持久化的多 agent 记忆和规划 - 强化 RELIASTRA 的审计链和灾难恢复路径，以适应生产规模 - 继续进行 AWS IAM 攻击路径图研究 ## 联系方式 - GitHub — [github.com/emmanueladesina](https://github.com/emmanueladesina) - Hashnode — [hashnode.com/@emmanueladeshina01](https://hashnode.com/@emmanueladeshina01) - 邮箱 — [E.adeshina@proton.me](mailto:E.adeshina@proton.me) - 开源 — Kubernetes 贡献者，云原生基础设施

标签：AI基础设施, 分布式系统, 后端架构, 响应大小分析, 多线程, 子域名突变, 平台工程, 搜索引擎查询, 日志审计, 测试用例, 漏洞利用检测, 请求拦截, 负责任AI, 逆向工具