一、前言
自从大多数web架构从单体演进到服务拆分,到微服务一统天下的几年来,应该没有web应用不是微服务架构的吧。最开始是阿里的doubble分层架构,到后来的SpringCloud全家桶,还有各个大厂自己定义的一套服务治理框架。微服务无处不在,如果你的系统不是微服务的就会被人耻笑落后和垃圾。情况就是这样。微服务确实给web系统开发和治理带来很多的便利性,特别是随着系统越来越复杂的业务。但是是不是业务越复杂也适合用微服务架构呢。显然不是,如果涉及的微服务上千上万,那就有点适得其反。所以个人认为微服务架构适合大中型web项目架构。特别复杂的还有特殊场景下的项目可能并不是很适合。
二、微服务架构要素
1、 Provider(服务提供者)绑定指定端口并启动服务
2、提供者连接注册中心,并发本机 IP、端口、应用信息和服务信息发送至注册中心存储
3、Consumer(消费者),连接注册中心 ,并发送应用信息、所求服务信息至注册中心
4、注册中心根据消费者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
5、Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
6、Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer设计的原因:
Consumer 与 Provider 解偶,双方都可以横向增减节点数。注册中心对本身可做对等集群,可动态增减节点,并且任意一台宕掉后,将自动切换到另一台
7、去中心化,双方不直接依赖注册中心,即使注册中心全部宕机短时间内也不会影响服务的调用(Consumer应用缓存中保留提供者 Provider 列表)
8、服务提供者无状态,任意一台宕掉后,不影响使用
注册中心包含如下功能:注册中心、服务注册和反注册、心跳监测与汇报、服务订阅、服务变更查询、集群部署、服务健康状态检测、服务状态变更通知等
三、微服务架构的利与弊
1、单体架构到微服务的演进
2、微服务的优点:文章来源:https://www.toymoban.com/news/detail-756692.html
- 灵活性高:它将应用程序分解为小型服务(松散耦合),使其开发、维护更快,更易于理解,可以提供更高的灵活性;
- 独立扩展:它使每个服务能够独立扩展,将系统中的不同功能模块拆分成多个不同的服务,这些服务进行独立地开发和部署,每个服务都运行在自己的进程内,这样每个服务的更新都不会影响其他服务的运行;
- 支持多种编程语言:微服务可通过最佳及最合适的不同的编程语言与工具进行开发,能够做到有的放矢地解决针对性问题;
- 自动部署与持续集成工具集成:它允许以灵活的方式将自动部署与持续集成工具集成,例如Jenkins,Hudson等;
- 通用性:通过服务实现应用的组件化(按功能拆分、可独立部署和维护),围绕业务能力组织服务,根据业务不同的需求进行不同组件的使用,所做产品非项目化,对于平台具有一定的通用性。
3、微服务的缺点:文章来源地址https://www.toymoban.com/news/detail-756692.html
- 处理故障难度高:微服务架构是一个分布式系统,必须构建一个相互通信机制并处理部分故障;
- 部署工作量大:整体式应用程序可以部署在负载平衡器后面的相同服务器上。但对于微服务,每个服务都有不同的实例,每个实例都需要配置、部署、缩放和监控;
- 测试复杂度高:微服务在一定程度上也会导致系统变得越来越复杂,增加了集成测试的复杂度;
- 运营成本增加:整体应用可能只需部署至一小片应用服务区集群,而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务,并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成,可能需要40~60个进程;
- 发布风险高:把系统分为多个协作组件后会产生新的接口,这意味着简单的交叉变化可能需要改变许多组件,并需协调一起发布。在实际环境中,一个新品发布可能被迫同时发布大量服务,由于集成点的大量增加,微服务架构会有更高的发布风险;
- 分布性系统问题:作为一种分布式系统,微服务引入了复杂性和其他若干问题,例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等,开发人员需要考虑以上的分布式系统问题。
到了这里,关于微服务的利与弊的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!