什么是微服务
微服务没有一个明确的定义,只能通过和传统的服务对比,才比较好理解什么是微服务.
传统服务是将绝大多数的业务 api 都集成在一个工程里.
优点是:
- 开发简单直接，集中式管理
- 基本不会重复开发
- 功能都在本地，没有分布式的管理开销和调用开销
但是同样的,缺点也很多:
- 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
- 代码维护难：代码功能耦合在一起，新人不知道何从下手
- 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
- 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
- 扩展性不够：无法满足高并发情况下的业务需求
所以对比之下就有了微服务架构.其思路大致上来说,就是将原来庞大的工程拆分成n 个小的,互相连接的工程.
比如原来是整个电商系统的后端服务,现在拆分成:
- 用户服务
- 商品服务
- 订单服务
- 物流服务
- 等等…
不同的业务访问不同的服务,听起来似乎对前端很不友好,不同的业务我需要请求不同的服务器,其实不是的,在这些微服务之前,还有一个 api-gateway 来负责服务路由、负载均衡、缓存、访问控制和鉴权等任务,对前端来说整个架构就是透明的.
整体架构图大致上是这样
微服务有什么优点
微服务架构有很多重要的优点。
它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。
这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。
微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。
微服务有什么缺点
微服务的缺点主要是系统整体比较复杂,服务之间需要互相调用或者通信,并且对这些服务进行监控与管理.
- API Gateway
- 服务间调用
- 服务发现
- 服务容错
- 服务部署
- 数据调用
所以我们需要一个工具来做弥补缺点
微服务的缺点并不是无法解决的,我们可以使用一套工具或者框架来去管理我们的微服务.
比如使用:Service Mesh
现在 docker 的使用变得越来越成熟,而容器非常的切合微服务的理念.加上使用 K8S 做容器的管理,再使用其他工具做 Service Mesh. 整个系统都会变得有序且可控.
系统结构
Istio
Istio是一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络，具备负载均衡、服务间认证、监控等功能，而不需要改动任何服务代码。想要为服务增加对Istio的支持，您只需要在环境中部署一个特殊的边车（sidecar），使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。
Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能：
- 流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
- 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
- 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
- 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。