以微服务方式构建企业应用程序——网络研讨会总结

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

上周,我们完成了微服务架构网络研讨会系列,参与人数创历史新高。除了上次网络研讨会的一些音质问题外,一切都很顺利。

您可以在这里注册观看录音: http://bit.ly/msa-webinars

本次网络研讨会系列分为三个部分:

  • 微服务:好的、坏的和丑陋的
  • 微服务:绿地或棕地
  • 使用微服务持续交付

第一个包括 Adrian Cockcroft 和 Arun Gupta 对使用微服务的动机和好处的概述。第二篇介绍了 Babak Mozaffari、Siamak Sadeghianfar 和我自己迁移到微服务架构的参考架构和经验。最后一个解释了微服务和 DevOps 之间的相关性,使用 James Rawlings 和我自己使用 Fabric8 和 OpenShift 进行持续交付的现场演示。

微服务的动机

我相信大多数软件架构师或开发人员看到并立即认识到持续交付和微服务架构的好处,但有时很难说服管理层迁移或开始使用微服务。一切照旧通常被视为风险较小的做事方式。如果您的组织中存在这种情况,那么向管理层提供一堆使用微服务的技术原因往往会失败。相反,您需要阐明商业利益。可以使用表示为循环的 OODA 模型来描述这样的商业利益之一。这个想法是,您迭代循环的速度越快,您作为一个组织的竞争力就越大。

Adrian 的演讲(在第一次网络研讨会中)提供了很多关于 DevOps 和微服务动机的有用信息。

规划微服务

当要求红帽全球专业服务帮助组织向微服务转型时,第一步始终是对当前状态进行分析。是否存在首先必须解决的技术、文化或组织障碍?采用微服务的直接和长期好处是什么?竞争对手有多成熟?

这些是您在计划实施微服务之前应该得到答案的问题示例。

下一步是定义基于微服务的未来状态,并阐明采用微服务的业务优势。

当长期目标确立并被股东接受时,我们就准备好推进实际转型。

转型

向微服务和 DevOps 的转变可能会有所不同,具体取决于对当前和未来状态的分析结果。有时最好的方法是创建新的组织,使用微服务重新实现现有的和新的应用程序。有时应用程序的逐步迁移更好。

在我参与的其中一个项目中,当前所述的分析表明该组织在实施微服务方面存在诸多障碍。例如,即使开发部门最近开始工作 g 根据敏捷原则,IT 部门的其余部分仍然组织在他们之间的隔离部门墙中。从确定可能的改进到发布并投入生产的时间将近 1 年。每个季度只允许发布一次新版本,而且这些版本通常很复杂而且经常失败。他们拥有大量未打补丁和不受支持的软件技术部门。在这种情况下,我们建议进行绿地转型,这意味着创建一个平行组织,其中包含一种由开发人员、测试人员、运营人员等组成的垂直团队组织的新文化。新组织随后取代旧应用程序,同时开始添加新功能已经积压了很长时间。 6 个月后,超过一半的应用程序被转换到新组织。

在另一个项目中,该组织当前状态的分析师展示了一个相当成熟的组织,拥有小团队,没有太多障碍。相反,他们面临的挑战是应用程序变得过于庞大和复杂,而且他们在扩展方面遇到了问题。由于客户需求,他们还必须维护同一应用程序的多个版本。在这里,转型项目要容易得多,也不需要创建平行组织。相反,大型应用程序被分解成更小的服务。实现更多管理部分,这些部分更易于扩展,并且可以使用同一服务的多个版本。

容器和微服务

本网络研讨会系列中的示例和演示均使用容器制作。尽管这不是微服务的要求,但使用容器的灵活性和速度非常适合。 Adrian Cockcroft 强烈支持使用容器作为微服务架构的运行时。容器,尤其是 Docker 最近被指责不够安全,即使许多安全漏洞不得不更多地关注人们维护他们的图像而不是容器运行时本身,这些担忧也有一定的道理。 Red Hat Enterprise Linux (RHEL) Atomic 将坚如磐石、功能强大且安全的操作系统与以 Docker 格式编写的容器相结合,因此是任何考虑微服务的人的自然选择。此外,OpenShift Enterprise 建立在 RHEL Atomic 之上,并提供编排和自助服务来实现这种自动化。

为不同的中间件使用可公开下载的图像是开始使用 Docker 容器的一种简单方法,但老实说,您必须非常勇敢才能在生产环境中使用这些图像。今天在 Docker 社区中缺少的是一条信任链​​,我们可以在其中相信镜像是在安全且正确配置的软件和操作系统堆栈上构建的。在我们拥有一个可以信任图像的回声系统之前,我们需要控制创建容器。 Red Hat OpenShift Enterprise 使用分层的 docker 镜像提供此控制,其中 Red Hat 提供您可以扩展的安全 docker 镜像。您可以从简单的 RHEL 映像开始,也可以使用包含预安装中间件(如 JBoss Enterprise Application Server)的映像。无论哪种方式,红帽都会承担责任并确保这些图像的信任链。


开班

DevOps 和微服务架构紧密结合。 OpenShift Enterprise 是两者的绝佳平台。目前它包括用于流行框架和产品的容器,如 NodeJS、Ruby、Perl、JBoss 企业应用程序平台、PostgresDB、MariaDB、MongoDB 等。Red Hat 的 xPaaS 团队目前正致力于添加更多中间件产品,如 JBoss Data Grid、JBoss BPM 套件(包括 JBoss BRMS)和 JBoss Fuse。

幻灯片

当您注册观看点播网络研讨会时,也可以下载这些幻灯片。

使用微服务进行持续交付的幻灯片:

认可

特别感谢 Adrian Cockcroft、Arun Gupta、Babak Mozaffari、Siamak Sadeghianfar 和 James Rawlings 参与并为网络研讨会系列创作了精彩内容。