重构那个让每次发布都成为风险的应用
云原生开发，是把软件设计并构建为运行在托管云服务之上，并在设计需要的地方采用容器和服务边界。SEYA Group 以这种方式构建新产品，也把现有应用重构到这种架构上，服务于那些软件能用、但改起来已经太慢或风险太高的团队。
适用对象
拥有一款创造营收的应用、却把每次发布都当作风险的 CTO 和工程副总裁。被要求拆分单体应用、希望就拆分边界听取第二意见的解决方案架构师。应用被原样搬上云、仍带着数据中心时代的假设，结果云账单涨了而发布节奏没变的 IT 经理。
如果您需要以最小改动迁移大量工作负载，那属于 云平台与迁移。 本页面讲的是需要改变设计的那个应用。
我们解决的问题
- 一个无法安全修改的产品，因为每个部分都依赖其他所有部分。
- 围绕固定服务器、共享磁盘或无法扩展的单一数据库而形成的代码库。
- 假定只有一个可部署单元、一个环境和一个维护窗口的发布路径。
- 需要构建一个新服务，但这里没有关于服务该如何构建的既定模式。
- 手工连接的集成，任何一方变更都会断掉。
您将获得
- 目标设计。应用如何拆分为服务，容器、Kubernetes、无服务器函数或更简单的运行时各自适合放在哪里，以及哪些托管服务可以替代您自己运维的部分。
- 可运行的软件。新产品或重构后的应用，与您的工程师一起、在您的代码仓库中、在您的云账户上构建。
- 交付路径。这些服务的构建、测试和发布流水线，使每个服务都能独立上线。
- 接口。其他系统可以用一致方式调用的 API 和集成边界，并为使用方团队编写文档。
- 切换计划。对于重构项目，一份书面说明，写明哪些行为必须保持正常，以及流量如何从旧系统转向新系统。
项目如何开展
- 架构沟通会。您带我们了解这个应用、它造成的限制，以及不能出问题的行为。
- 设计。我们与您的团队一起阅读代码和运维历史，提出服务边界和运行时方案，并商定第一个增量。
- 增量构建。服务逐个构建、测试、发布，您的工程师结对参与，让模式真正留下来。
- 切换与交接。流量按计划迁移，旧路径在您认可后下线，运行中的系统由您的团队拥有。
技术范围
SEYA 曾在 AWS、Microsoft Azure 和 Google Cloud 上构建和重构应用。容器方面用过 Docker、Kubernetes（包括 Amazon EKS 和 Google Kubernetes Engine）、Istio 和 OpenShift；无服务器方面用过 AWS Lambda。应用代码涉及 Java（Spring Boot 与 Spring Cloud）、Node.js 和 Python。交付流水线用过 Jenkins 和 GitHub Actions，服务所依赖的基础设施则用 Terraform 定义。架构需要时我们推荐 Kubernetes，不需要时推荐更简单的运行时。
您需要具备的条件
一位能对各项行为的重要性排序的产品负责人、愿意与我们协作并最终接手成果的工程师，以及一个可供服务运行的云账户。如果基础环境尚不存在，先做 云平台与迁移 中的着陆区部分。流水线中的安全检查在 安全与 DevSecOps 下设计，团队组织方式的调整则属于 企业转型。
本页不在范围内的内容：用一份简报覆盖整个应用组合的现代化计划（项目只覆盖简报中指定的应用）、品牌或市场营销工作，以及交接后替您运维 Kubernetes 集群。
安全
应用的流水线检查、密钥处理和准入规则在 DevSecOps 下设计。本页面覆盖的是应用构建，不能替代那项评审，也不对结果进行认证。
相关案例
常见问题
我们必须用 Kubernetes 吗？
不必。Kubernetes 只是选项之一，而且有运维成本。设计阶段会推荐适合该应用及其运维团队的运行时，有时是托管容器服务，有时是无服务器函数。
代码归谁所有？
归您。从第一次提交起，工作就在您的代码仓库中、在您的许可证下进行。不存在任何让您产生依赖的 SEYA 框架。
你们如何与我们的工程师协作？
作为一个团队。SEYA 工程师与您的工程师在设计和实现上结对，评审走您的正常流程。目标是您的团队在没有我们的情况下也能继续前进。
重构期间旧应用可以继续运行吗？
这是常规做法。切换计划写明哪些行为必须保持正常，并分阶段迁移流量，业务在新服务接管的过程中持续运转。
设计阶段需要多长时间？
取决于应用的规模，以及其行为有多少已有文档或测试覆盖。我们在架构沟通会上商定设计阶段的范围，如果需要扩大，会告知您。
如果某一个应用正在拖慢您整个产品路线图，请 预约应用架构沟通会， 我们会告诉您我们会从哪里着手。
联系我们
发送有关云、平台、数据或可靠性项目的咨询。营销邮件在表单中为单独选项。