加入收藏 | 设为首页 | 会员中心 | 我要投稿 PHP编程网 - 黄冈站长网 (http://www.0713zz.com/)- 数据应用、建站、人体识别、智能机器人、语音技术!
当前位置: 首页 > 云计算 > 正文

微服务架构如何选?

发布时间:2022-09-11 00:28:10 所属栏目:云计算 来源:互联网
导读:微服务是应用现代化趋势下的必然选择 随着数字经济的不断发展,企业面临着更加多样化、敏捷化的新时代IT需求。 用户行为的变化:业务应用的用户访问不可预估,突发性访问增多,存在临时热点事件或大促期间等不可控业务高峰期。 业务模式的变化:所有业务访
  微服务是应用现代化趋势下的必然选择
 
  随着数字经济的不断发展,企业面临着更加多样化、敏捷化的新时代IT需求。
 
  用户行为的变化:业务应用的用户访问不可预估,突发性访问增多,存在临时热点事件或大促期间等不可控业务高峰期。
 
  业务模式的变化:所有业务访问都是通过互联网渠道,包括Web、手机App、微信小程序等。
 
  业务系统开发的变化:应用再也不像以前半年或一年进行规划,随时会有需求变化,两周一个迭代成为常态。业务应用交付周期短,质量要求高。
 
  运维模式的变化:要求全天候值守,在线升级和快速响应,不同团队特别是外包团队使用不同的技术栈,无法统一管控。
 
  因此,评估一家企业是否需要采用微服务架构,往往考察这五大关键条件:数据量和业务复杂度,团队规模,应对业务流量变化,是否需求足够的容错容灾,以及功能重复度和差错成本。
 
  在日益激烈的数字化竞争下,企业必须更快地拥抱市场变化、随时响应新的用户需求,比对手更迅速地将产品推向市场。
 
  微服务作为加速企业提升敏捷创新能力的重要抓手,能够帮助企业快速实现独立更新和部署应用,快速应对市场变化,逐渐成为企业加速应用现代化的必然选择。
 
  微服务架构怎么选?
 
  Istio
 
  Istio 是当前Service Mesh形态上比较热门的实现方案,能够和K8s深度结合,更快速、更便捷地实现服务治理。Istio 提供了一种简单的方法,来创建一个提供负载均衡、服务间认证、监控等的服务网络,且不需要对服务代码进行任何更改。通过在整个环境中部署专门的 sidecar 代理服务,来拦截微服务间的所有网络通信,整个配置和管理通过 Istio的控制面板来做。
 
  作为新一代的微服务架构,它的微服务治理与开发更彻底解耦,适应场景更广泛,很多企业都正在逐步从Spring Cloud向 Service Mesh过渡;但也正是因为技术比较新,企业自研需要一定的学习成本,打破传统IT运维/开发壁垒,考虑引入专业的技术厂商则能够完美地解决这一问题。
 
  Dubbo
 
  Dubbo是比较早期的一款微服务架构,可以使得应用通过高性能的 RPC 实现服务的输出和输入功能,和Spring框架无缝集成。
 
  优点是RPC长连接+NIO,性能更高;但协议的局限性,会限制生态发展和兼容性。
 
  Spring Cloud
 
  Spring Cloud是基于Spring Boot的一整套实现微服务的框架,提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线等组件。Spring Cloud包含了非常多的子框架,其中,Spring Cloud Netflix是其中一套框架,由Netflix开发后来又并入Spring Cloud大家庭,它主要提供的模块包括:服务发现、断路器和监控、智能路由、客户端负载均衡等。
 
  Spring Cloud拥有更成熟的Spring社区生态,更多成熟的企业应用案例;但也存在一定不足,比如跨语言平台问题、微服务治理对代码侵入性较强。

  微服务架构如何选?

       为Istio的基本运行原理:
 
  当用户向 Kubernetes 提交一份新的配置,首先会触发 galley 注册在 kubernetes 中的webhook,webhook 会检查配置是否合法,如图中的步骤1。
 
  若配置无法通过校验,则 kubernetes将拒绝用户提交的配置,并给出相应的错误信息。如图步骤2。
 
  当配置通过校验后,通过 kubernetes 的通知机制,galley得到配置变更信息。
 
  Galley 将变更的配置/服务信息转换为 MCP 的格式通过 MCP 协议推送给pilot,如图步骤4。
 
  最后一步,pilot 通过 xDS 协议向数据平面推送变更的配置。
 
  以上为当前常见的微服务架构,那么企业实际改造时应该怎么做呢?我们建议:
 
  不同类型的应用均可以通过微服务能力进化到现代化应用。
 
  需要为传统应用提供一条稳妥的转型路径
 
  需要为SpringCloud应用提供一条贴合云原生的、无需大规模适配的转型路径。
 
  微服务架构如何设计?
 
  首先从微服务的定义来看,微服务是一起合作的独立小服务单元,可以同步异步调用,也可以独立拆分、独立部署、独立升级,后端中间件、存储资源、数据库等也是独立的,最佳实践是每个微服务都有自己的database,真正意义上实现微服务应用解耦。
 
  接下来,我们从微服务的必备基础理论,也是企业进行微服务所需遵循的一大原则——康威定律来看:
 
  组织形式等同系统设计。设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。
 
  第一定律:Communication dictates design(组织沟通方式会通过系统设计表达出来)。
 
  人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理。在团队内部进行频繁的、细粒度的沟通。对于团队外部,定义好接口,契约,只进行粗粒度的沟通。这样可以降低沟通成本,同时也符合高内聚,低耦合原则。
 
  第二定律:There is never enough time to do something right, but there is always enough time to do it over(时间再多一件事情也不可能做的完美,但总有时间做完一件事情)。
 
  复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的。因此企业需要拥抱变化,解决当下,先完成一个一个小目标。
 
  第三定律:There is a homomorphism from the linear graph of a system to the linear graph of its design organization(线型系统和线型组织架构间有潜在的异质同态特性)。
 
  你想要什么样的系统,就搭建什么样的团队,反之亦然。
 
  第四定律:The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems(大的系统组织总是比小系统更倾向于分解)。
 
  一个大的组织因为沟通成本/管理问题,总会被拆分成一个个小团队(2 pizza team)。
 
  具体来说,企业在进行微服务架构改造时,可以遵循以下标准:
 
  分布式服务组成的系统。
 
  按照业务而不是技术来划分组织。
 
  做有生命的产品而不是项目。
 
  去中心化。
 
  自动化运维(DevOps)。
 
  容错。
 
  快速演化。
 
  同时,根据企业的自身组织架构情况和业务情况进行针对性规划设计。
 

(编辑:PHP编程网 - 黄冈站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读