在没有微服务之前,系统架构都是单体服务,但是单体服务缺点很多,比如不灵活、不可靠、不可扩展、不适合复杂应用程序等。所以促使了微服务的发展,那么微服务到底是什么样的?本文笔者与大家讨论一下。
微服务是一种架构风格,应用程序被划分为更小的、流程驱动的服务,这些服务松散耦合、可独立部署,并且能够通过定义良好的 API 进行通信,这些服务是为业务功能而构建的。
如图,微服务架构中一般都有一个网关,用户在访问系统的时候,会首先访问网关,由网关决定将请求映射到哪个服务。
微服务具有以下特点:
单体服务是一个实现所有功能的大型代码库,所有的代码都在一个地方,没有一个组件可以孤立地工作,这意味着应用程序必须作为一个整体进行测试。从好的方面来说,单体应用很容易启动和运行。
然而,随着公司的发展和团队规模的扩大,单体开发变得更加困难,难以管理。
基于微服务架构构建的应用程序将应用程序的每个部分拆分为执行一项特定任务的独立代码库,每个组件都可以独立于其他模块进行部署和扩展。然后,这些模块通过应用程序编程接口 (API) 相互通信,以创建应用程序的全部功能。
微服务架构构建的软件被分解为众多组件服务,每个服务都可以独立创建、部署和更新,而不会影响应用程序的完整性,整个应用程序可以通过调整一些特定的服务来扩展,而不是关闭并重新部署它。
使用微服务架构构建的应用程序失败并不容易,当然,个别服务可能会失败,这无疑会影响运营,毕竟,在微服务环境中,众多不同且独特的服务相互通信以进行操作,并且在某些时候必然会发生故障。
但是,在正确配置的基于微服务的应用程序中,面临停机的功能应该能够将流量重新路由到自身之外,同时允许其连接的服务继续运行,通过监控微服务并在出现故障时尽快恢复它们,也很容易降低中断风险。
每个微服务都可以在不同的技术和平台上开发。因此,去中心化治理。构建微服务的一种方法是生成有用的工具,然后可以在社区中使用这些工具来解决相同的问题。
去中心化治理伴随着去中心化数据管理。 微服务应用程序包含并管理其独特的数据库。相比之下,单体应用跨不同应用程序使用单个逻辑数据库。
创建微服务架构是为了专注于满足现代数字业务的需求,传统的单体架构让团队致力于开发 UI、技术层、数据库和服务器端逻辑等功能,另一方面,微服务依赖于跨职能团队,每个团队负责创建基于通过消息总线传输和接收数据的单独服务的特定产品。
微服务是一种创建云应用程序的架构方法,每个应用程序都构建为一组服务,每个服务都在自己的进程中运行并通过 API 进行通信。本文主要介绍了微服务的概念、特点、优势等,希望本文对您认识微服务有所帮助,有任何问题欢迎在下方评论区与我讨论。