®
01
分布式架构会改变事务和错误的处理方式
跨越多个服务的业务，并不天然拥有统一的数据库事务。我们会规划状态转换、暂时的不一致情况和补偿操作。发件箱（Outbox）模式有助于将数据变更与待发布的事件一致地关联起来。重试需要业务层面的幂等性，也就是重复处理时能得到确定的结果。超时时间和依赖关系会被加以限制，避免某个响应缓慢的服务拖住整条链路。相关团队必须能够理解并测试这些规则。
您对 OTOKO® 的委托
我们为您承接的工作。
我们与业务部门和开发团队共同梳理术语、规则和变更需求。经常需要同步调整的功能，不应被轻率地拆分开来。模块化单体应用可以在不引入分布式运维的情况下建立清晰的边界。而当独立团队、负载特征或交付周期能够带来可论证的收益时，微服务才值得考虑。相关决定连同其运维后果会一并记录在案，而不是仅仅根据潮流来选择架构。
可能的服务范围
- 与业务部门共同完成领域划分，采用事件风暴（Event Storming）和限界上下文（Bounded Context）方法
- 基于 Kubernetes 的平台，配合 Helm、GitOps 交付方式，并按团队划分命名空间
- 服务间通过 REST、gRPC 或消息进行通信，并使用服务网格（Service Mesh）实现加密和路由
- 按服务分别管理数据，采用 Saga 模式和发件箱（Outbox）模式处理分布式事务
- 涵盖日志记录、配置、机密信息和容错能力的运维规则
具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。
把技术讲清楚
我们是这样落实任务的。
02
先具备运维能力，再进一步拆分
每个新服务都需要明确的负责人、监控、配置和安全的交付方式。我们会测试选定的局部故障场景，并观察完整业务，而不只是单个容器的状态。移交内容包括架构决策、接口契约和运维手册。现有瓶颈、团队结构和发布依赖关系，是首次评估最重要的输入信息。
一个可验证的成果
这将成为您后续工作的基础。
- 领域模型，含服务划分与接口
- 平台及以代码形式实现的交付流水线
- 运维手册，含各服务的运维规则
移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。
您的项目详情
在有利于您产品的地方划定服务边界。
我们会审视一个应用中哪些部分适合独立变更和独立运维。微服务只是众多架构方案之一；真正起决定作用的是业务边界的划分、团队职责的分工，以及可控的运维流程。
在技术拆分之前，先明确职责与数据归属
每个服务都需要一个清晰易懂的业务定位。在拆分出某个组件之前，我们会先研究相关流程、数据归属和变更依赖关系。如果多个服务共用同一批数据表、且必须始终一起发布，那么最终往往只会形成一种分布式的依赖关系，却未能带来预期的收益。
我们会区分同步查询与异步流程步骤。对于跨多个服务的业务流程，中间状态和补偿机制会被明确建模。例如，取消一项预订是一种业务行为，而不是对所有数据库进行随意的技术回滚。
让分布式故障变得可见并可以处理
服务数量增多会带来额外的网络路径，也可能导致部分故障。我们会规划超时、限流和重试机制，使某个响应缓慢的服务不会拖垮整个应用。自动重试的前提是，某项操作不会因此被无意中重复执行。
推行工作会先从一个范围明确、收益可衡量的领域开始。围绕日志、链路追踪、部署和值守待命制定统一标准，可以避免每个服务各自制定运维规则。如果预期收益无法证明投入的合理性，一个结构清晰的模块化应用仍可能是更合适的方案。
示例项目场景
该服务在日常工作中如何发挥作用。
示例：文档生成环节在负载高峰时拖慢了某个业务应用。我们会审查其业务和技术方面的依赖关系，并在必要时将这一处理流程单独拆分出来。处理结果会通过明确的任务状态提供，而核心流程则可以继续按可控的方式运行。
该示例说明的是一种可能的流程，并非客户案例。
在迈出第一步之前
您关于 微服务 的问题。
为此必须使用 Kubernetes 吗？
不一定。运维模式取决于服务的数量、扩展需求和具体要求。Kubernetes 可能适用，但对于按业务拆分的应用而言，并非必备条件。
这样做是否总能加快开发速度？
不一定。分布式系统会带来额外的协调工作和运维负担。我们会结合您实际的依赖关系和瓶颈来评估其收益。
