SOA 与微服务
为什么采用微服务架构?
SOA(面向服务架构)和微服务是两种不同的 Web 应用程序开发架构。面向服务架构侧重于在整个 Web 应用程序中重用服务和组件,通过减少冗余来减少代码编写工作量。服务是代码和数据的集成,用于构建和执行功能;例如,同步电子邮件、使用 Cookie 验证登录用户、发送通知。而微服务架构则侧重于应用程序的高可靠性和可用性,即使必须调整数据资源和代码中的冗余。Web 应用程序中的每个功能都以服务的形式开发,然后被容器化并托管在单独的服务器实例上。这种方法增强了 Web 应用程序的灵活性,即使某些服务出现故障,应用程序也能继续运行。
在SOA 架构中,整个后端系统应用程序分为三个部分,即控制器、服务和业务逻辑。整个后端系统托管在单个服务器实例上,后端系统中的服务可以直接相互通信,但对于外部世界(前端和第三方应用),这些服务是通过 API 调用来访问的。而在微服务架构中,这些服务作为独立的应用程序在各自的服务器实例上开发和部署。在微服务架构中,服务之间的通信也通过 API 进行。
何时使用 SOA(面向服务架构)?
无论何时构建具有以下愿望的 Web 应用程序,都应使用面向服务的架构:
- 谁的用户可以承受停机时间?
- 当需要的 Web 应用程序预算比高弹性 Web 应用程序相对较少时。
- 当企业主希望通过将每个企业应用程序迁移到云端来节省服务器和设备维护成本时。
- 大型 Web 应用程序需要在较短的时间内开发。
- 当单点故障是可以容忍的时候。
- 当数据冗余是可以容忍的时候。
SOA 架构的优势和好处
- 由于 SOA 专注于在整个 Web 应用程序中重用服务,因此开发速度更快。
- 更快的开发速度意味着更低的 Web 应用程序开发成本。
- 以 SOA 编写的代码易于阅读和管理。
- SOA 中的部署更容易,因为 Web 应用程序仅部署在单个服务器实例上。
- 运行以 SOA 开发的 Web 应用程序的服务器成本非常低。
- 企业不需要为应用程序的多个版本提供支持,因为新应用程序的推出是在生产服务器实例上完成的,因此每个人都可以同时使用。
面向服务架构的缺点
- 数据和服务的极端可重用性导致了极端的可靠性,这通常会成为整个 Web 应用程序的单点故障。
- 需要一个大型服务器实例来托管 Web 应用程序,这会对数据总线和网络通信带宽等硬件产生限制。
- 部署此类基于 SOA 架构的大型 Web 应用程序需要耗费大量时间才能部署并稳定发布。这也是为什么这类 Web 应用程序的部署通常安排在周末的主要原因。
- SOA 中的 Web 应用程序开发依赖于单一编程语言或框架。在开发过程中,经常会发生这样的情况:某个开源功能或更好的实现虽然可以用其他编程语言实现,但开发团队无法在其应用程序中使用。在这种情况下,开发团队还必须开发该功能,这会增加开发成本和时间。
为什么采用微服务架构?
微服务架构的工作原理是将 Web 应用程序中的所有内容分散化。微服务架构通过适应服务器实例的冗余和数据重复,提供了高弹性和高可用性。这种冗余和重复降低了 Web 应用程序开发和部署过程的成本效率。由于服务作为独立的应用程序部署在各自的服务器实例上,并在服务调用请求激增时准备运行备份容器,因此故障阈值被推高。硬件资源的高可用性使应用程序能够提供高弹性。分布在独立服务上的应用程序工作负载实现了高可用性,因为即使某些服务停止工作,Web 应用程序也不会失败。跨区域复制可保护数据免受风险并提供低延迟。
何时使用微服务架构?
无论何时构建具有以下愿望的 Web 应用程序,都应该使用微服务架构:
- 当需要零停机时间时。
- 当 Web 应用程序开发和部署成本不再是人们关心的问题,而是高弹性和可用性时。
- 当单点故障无法容忍时。
- 当您有充足的时间来开发 Web 应用程序时。
微服务架构的优势
- 微服务架构提供高可用性、可靠性、弹性和低延迟(当应用程序请求重定向到最近的部署服务器时)。
- 应用程序敏捷、灵活且易于扩展。
- 由于每个服务都可以独立开发,因此 Web 应用程序变得独立于编程语言和框架。
- 部署过程更加顺畅,因为它是逐个服务完成的,因此通常不会出现 Web 应用程序停机。
- 服务器实例和云托管计划的选择与服务的用例和使用频率相关,因此消除了对大型服务器实例的依赖。
微服务架构的缺点
- 由于结构复杂,开发过程极其耗时且繁琐,部署也是如此,因为新功能的部署必须逐个服务地进行。
- 需要额外的基础设施来观察、监控和保护服务部署。
- 与基于 SOA 开发的 Web 应用程序相比,其开发和部署难度相对较高。
- 您必须雇用具有相对较多技能的开发人员。
来源:Decipher
文章来源:https://dev.to/priyanshi_sharma/soa-vs-microservices-59m4