Kevin Webber 在开始演讲的时候说，企业软件构建应用程序的形式比较散碎，不够系统，集成很复杂。传统的基础架构（Traditional infrastructures）具备主动 / 被动的粗糙故障转移（crude failover），支持在主动和被动系统之间复制复杂的状态。
在一个现代化项目中，架构师必须做出的最初几项决定（“第一英里（The First mile）”）是至关重要的。他不仅谈到了关键的架构决策，也提及了如何根据领域驱动设计（ Domain-Driven Design）的原则来做出这些决策。为了定义所涉及的业务过程以及如何将这些过程转换为事件驱动（event-driven）系统，事件风暴（Event storming）将关键的利益相关者聚集到一个协作的环境中。团队应该关注在业务中已经发生的最有趣的事件。
在从遗留系统（legacy sysems）到反应系统（Reactive systems）的迁移中，其他一些诸如防护层 (ACL) 和 Strangler 模式的概念也同样有用。
洋葱架构（Onion architecture）与领域驱动设计（Domain Driven Design）的概念非常吻合。该架构中的以下几个层可以帮助实现不同方面的需求。
- 基础架构:我们可以使用该层来实现诸如健康检查、跟踪和身份验证等交叉需求（cross-cutting requirements）。
- API:用于路由和数据验证
- 域:管理这个层中的有界上下文
- 核心:这就是我们管理聚合（Aggregates）的地方
Webber 讨论了云原生对于应用程序的意义。应用程序需要是容器包装的、动态管理的和面向微服务的。
Webber 还谈到了微服务架构，他推荐道：团队首先应该从整体模型开始着手, 并使用微服务作为重构技术将系统分解成多个微服务。微服务模型不仅有助于分布式系统, 也有助于分布式团队。
很多团队专注于在服务级别上分解系统，但却在数据层保持耦合。在这样的架构中，任何数据模型都将影响多个服务。
在会议结束后，InfoQ 与Kevin 进行了交谈，了解了有关将Java 应用程序迁移到云基础架构上的更多详细信息。
Kevin 说到，一旦微服务有点对点的交互，那么在服务管理方面就会混乱。重要的是要记住， 如果一个微服务发生改变的时候影响了另一个，那么这种情况下它们就不算真正独立的微服务，两者应该整合为单一的服务。
微服务的构成可以利用 PubSub 模型来实现，PubSub 使用像 Kafka 之类的服务器， 先将事件发送到队列，再使用诸如 Cassandra 的 NoSQL 数据库将事件存储在事件日志存储（Event Log Store）中。
如果读者想要了解更多关于该话题的细节，可以在奥莱利（O’Reilly）中查阅 Webber 的 Mini 书《 Migrating Java to the Cloud》
查看英文原文： Kevin Webber on Migrating Java to the Cloud
感谢冬雨对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论