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 )关注我们。
评论