新乡公司做网站,泉州网站建设设计,域名信息,做app网站的软件叫什么名字吗一、前言
自从大多数web架构从单体演进到服务拆分#xff0c;到微服务一统天下的几年来#xff0c;应该没有web应用不是微服务架构的吧。最开始是阿里的doubble分层架构#xff0c;到后来的SpringCloud全家桶#xff0c;还有各个大厂自己定义的一套服务治理框架。微服务无…一、前言
自从大多数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、微服务的优点
灵活性高它将应用程序分解为小型服务松散耦合使其开发、维护更快更易于理解可以提供更高的灵活性独立扩展它使每个服务能够独立扩展将系统中的不同功能模块拆分成多个不同的服务这些服务进行独立地开发和部署每个服务都运行在自己的进程内这样每个服务的更新都不会影响其他服务的运行支持多种编程语言微服务可通过最佳及最合适的不同的编程语言与工具进行开发能够做到有的放矢地解决针对性问题自动部署与持续集成工具集成它允许以灵活的方式将自动部署与持续集成工具集成例如JenkinsHudson等通用性通过服务实现应用的组件化按功能拆分、可独立部署和维护围绕业务能力组织服务根据业务不同的需求进行不同组件的使用所做产品非项目化对于平台具有一定的通用性。 3、微服务的缺点
处理故障难度高微服务架构是一个分布式系统必须构建一个相互通信机制并处理部分故障部署工作量大整体式应用程序可以部署在负载平衡器后面的相同服务器上。但对于微服务每个服务都有不同的实例每个实例都需要配置、部署、缩放和监控测试复杂度高微服务在一定程度上也会导致系统变得越来越复杂增加了集成测试的复杂度运营成本增加整体应用可能只需部署至一小片应用服务区集群而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成可能需要40~60个进程发布风险高把系统分为多个协作组件后会产生新的接口这意味着简单的交叉变化可能需要改变许多组件并需协调一起发布。在实际环境中一个新品发布可能被迫同时发布大量服务由于集成点的大量增加微服务架构会有更高的发布风险分布性系统问题作为一种分布式系统微服务引入了复杂性和其他若干问题例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等开发人员需要考虑以上的分布式系统问题。
