大型互联网公司都会采用微服务,但是采用什么样的微服务架构设计模式呢?这就非常的重要了,本篇重点谈谈微服务设计@mikechen
微服务架构
首先,我从微服务谈起,这样大家更能了解微服务的本质。
微服务的本质:在于将一个复杂的大型应用程序,拆分为多个独立的小服务。
每个服务之间,通过轻量级的通信机制(比如:RPC、或者HTTP/REST、消息队列…等形式),交互通信。
整个架构,如下图所示:
1.单一职责
每个微服务,都围绕特定的业务功能或能力展开,聚焦于做一件事,并将其做好。
比如:用户服务、交易服务、商品服务…职责非常分明,每个服务专注自己的事情。
2.独立部署
每个微服务,一般都是采用“独立部署”,为什么要采用“独立部署”?
原因很简单:就是独立了后,可以单独开发、测试、部署、和扩展…等等。
通过这种方式,每个团队可以控制自己的节奏,不用担心别的团队影响到自己,本质是提高工作效率。
3.去中心化治理
微服务架构的本质:是提倡去中心化的管理方式,每个团队负责各自的微服务,就是我上面讲到的。
除了独立之外,还有一个好处,就是各个团队,可以使用最合适的技术栈,比如:你是Java的、Go、Php…等等。
都可以采用(多语言、多数据库…等),这样每个团队不用被编程语言限制,可以更好的发挥自己的特长。
最后,各个团队通过微服务框架,来解决通信。
比如:你可以使用RPC,也可以使用,比如:HTTP(RESTful APIs)等等,以及消息队列…都可以。
这种松耦合的通信方式使得服务之间的依赖性较低,有助于提升系统的弹性。
4.弹性与容错
通过将应用拆分为多个小服务,微服务架构可以更好地应对失败。
比如:某个服务出问题时,其他服务仍然能够继续工作。
服务可以通过负载均衡、限流、熔断…….等技术增强容错能力。
当你把上面的抓住了之后,你就需要具体运用哪种“微服务架构设计模式”了,下面我接着谈常见的“微服务设计模式”@mikechen
微服务数据共享设计
在微服务架构中,每个微服务应该拥有自己的独立数据存储,以保持自治性和独立性。
所以,大家要清楚这种模式,可以理解为“反模式”,只是一个“微服务过渡版”。
为什么说是“过渡”呢?原因很简单:多个微服务共享一个数据库,这种设计能更容易处理事务和一致性问题。
但会降低服务的独立性、和扩展性,不符合微服务的自治原则。
这一点,一定要非常清楚,否则就本末倒置了。
所以,你可以采用微服务数据共享,来过渡微服务。
如果你的团队还没有这么强的能力,可以采用这种模式来“过渡”,这一点要记住!
微服务聚合设计
微服务聚合设计:是指如何将多个微服务的数据、或行为进行组合,提供一个统一的接口、或功能。
这种设计模式,常见于需要将多个服务的响应整合为一个响应的场景,比如:用户界面调用“多个微服务”的情况。
举一个例子,前端请求用户详细信息,可以通过这种模式, 聚合用户服务、订单服务、支付服务…等等的数据,返回一个包含所有信息的响应。
这是这种模式的好处,但也有坏处。
比如:聚合操作可能需要等待多个微服务的响应,影响性能。
为此,可以使用异步请求、并行调用、或缓存机制来提高响应速度。
微服务代理设计
微服务代理设计:是通过在服务之间引入中间层(代理)来处理通信、负载均衡、安全…等非业务功能,简化微服务的实现并提升其灵活性。
比如:最典型的就是服务网格(Sidecar 代理模式),如下图所示:
在服务网格中,Sidecar 代理是服务网格的核心组件。
每个微服务实例旁边,部署一个 Sidecar 代理,Sidecar 是一个运行在主服务旁边的辅助进程。
服务网格(Sidecar 模式),可以帮助主服务处理非业务逻辑,如:日志、监控、安全认证…等任务。
Sidecar 代理模式允许微服务将一些基础设施功能分离出去,减少主服务的复杂性。
常见的有:Istio、Linkerd …等服务网格技术。
代理虽然有很多好处,但也要记住:代理层可能成为系统瓶颈。
因此需要优化代理的性能,防止其成为单点故障。
微服务异步消息设计
异步消息设计:主要是指通过消息队列、或事件,在微服务之间实现松耦合通信。
服务之间的交互不再是同步调用,而是通过异步消息传递信息,从而提高系统的扩展性、和性能。
比如:消息队列用于微服务之间的异步通信,一个微服务可以将消息发送到消息队列,另一个微服务从队列中消费消息。
这种模式,适用于任务队列、异步处理…等场景。
但是,这种模式,也需要考虑:消息系统必须确保消息不丢失(可靠性)/和幂等性等问题。
陈睿mikechen
10年+大厂架构经验,资深技术专家,就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号,获取更多技术干货!
后台回复【面试】即可获取《史上最全阿里Java面试题总结》,后台回复【架构】,即可获取《阿里架构师进阶专题全部合集》