您的位置:主页 > 公司服务 >

从单一应用到服务

本文摘要:之前微服务是怎么解释的?微服务的重点是服务治理。微服务架构是将庞大臃肿的单体应用拆分成细粒度的服务,每个拆分的服务独立打包部署,然后交付给一个小团队进行开发和运维,大大提高了应用交付的效率。 服务拆分什么时候举行?分辨单体的应用尺度有哪些?服务拆分什么时候举行?比如作为社交App,为了快速上线,验证可行性,只能开发首页信息流、评论等基本功能。产品上线后,经过一段时间的运营,用户开始逐渐增多,可行性验证通过。

英皇体育

之前微服务是怎么解释的?微服务的重点是服务治理。微服务架构是将庞大臃肿的单体应用拆分成细粒度的服务,每个拆分的服务独立打包部署,然后交付给一个小团队进行开发和运维,大大提高了应用交付的效率。

服务拆分什么时候举行?分辨单体的应用尺度有哪些?服务拆分什么时候举行?比如作为社交App,为了快速上线,验证可行性,只能开发首页信息流、评论等基本功能。产品上线后,经过一段时间的运营,用户开始逐渐增多,可行性验证通过。在下一阶段,需要添加更多的新功能来吸引更多的目标用户,例如在这个社交应用程序中添加个人主页显示和消息通知。

这时候就需要大规模的扩展开发者,支持多种功能的开发。如果此时继续接受单一的应用架构,混合多个功效模块进行开发、测试和部署,会导致不同功效之间的相互影响。打包部署在启动前需要进行所有功效测试。

此外,多个功能模块的混合是对在线服务稳定性的巨大挑战。再举个58到家的例子。随着业务越来越大,数据量越来越大,并发性也越来越大。15年来,58到家的架构遇到了各种问题:垂直业务拓展、家政、美容、快递、平台,一些类似的业务代码副本越来越严重。

数据量和并发性不断增加,庞大的底层架构不断向上游蔓延。所有挪用方都需要注意缓存和分发效率逐渐降低,jar包耦合,多个系统依赖一个共同的jar包,一个服务升级导致兼容性问题,影响其他服务的数据库耦合,多个服务共享一个数据库,相互耦合,相互影响。一个服务写了一个低质量的SQL,导致其他服务受到影响。

此时58到家开始服务拆分,找到共同的痛点,抽象共同的数据会议和子服务,然后沉入微服务。一般来说,一旦有超过10个人同时开发一个单一的应用,就会遇到上述问题,所以是时候考虑服务拆分了。服务拆分的两种姿态,那么如何具体实现服务拆分呢?最有效的手段之一是服务于不同的功效模块,独立部署和运行。以上面提到的社交App为例,可以认为首页信息流是服务,评论是服务,消息通知是服务,个人主页也是服务。

这种服务拆分方式是垂直拆分,从业务维度拆分。规模根据服务的相关程度确定。紧密关联的服务适合拆分成微服务,独立效率的服务适合拆分成微服务。

另一种服务拆分方式是横向拆分,从共同独立功效维度拆分。规模以是否存在被多个其他服务挪用的公共资源为基础,依赖的资源是独立的,不与其他服务耦合。以之前的社交App为例,无论是首页信息流、评论、消息框还是个人主页,都需要显示用户的昵称。如果将用户的昵称功能作为一个独立的服务单独部署,我只需要对这个服务进行任何更改就可以启动,其他服务不会受到影响,开发和启动成本也会大大降低。

服务拆分的前提条件一般来说,在业务系统中引入新技术肯定会带来架构的巨大升级。在做详细的解决方案之前,首先要意识到新架构会带来哪些新问题,以及你和你的团队能否解决这些问题。

怎么解决?你是投身于人力建设,还是接受行业开源方案?从单一应用程序迁移到微服务架构时,必须面对和解决以下问题。如何定义服务:对于单个应用,之前不同功效模块交互时,通常是以类库的形式提供各个模块的功效。对于微服务,每种服务都有自己的运行过程,通过接口向外界传递信息。

无论接受哪种通信协议,无论是HTTP还是RPC,服务之间的挪用都是通过接口形态学来约定的,约定的内容包括接口名称、接口参数和接口返回值。如何发布和订阅服务:由于单个应用部署在同一个WAR包中,所以接口之间的挪用属于课程内部的挪用。

被拆分成微服务,独立部署后,一个注册中心(如Zookeeper、尤里卡、Consul等。),可以记录每个服务商的地址,是服务盗用者查询所需要的。如何监控一个服务:对于一个服务,需要一个通用的监控方案,可以覆盖服务掩埋点、数据采集、数据处理惩罚、最后数据显示的整个环节效率。

如何管理服务:被拆分成微服务后,服务数量增加,依赖性变得巨大。例如,当一个服务有性能问题时,依赖的服务也会受到影响。可以设置挪用性能的阈值。

如果在一段时间内总是超过阈值,依赖于服务的挪用可以直接退回,即吹掉。如何定位故障:拆分成微服务后,一个用户挪用可能依赖多个服务,每个服务部署在不同的节点上。

如果用户盗用导致问题,则需要一种解决方案来标记用户请求,并在多个相关服务系统中继续报告该请求,以便所有路径可以串联连接来定位故障。要解决以上问题,需要有一个可行的解决方案,才能举行服务拆分。

综上所述,无论是垂直拆分还是水平拆分,都是将单个应用的复杂功能拆分,单独成单独的服务部署。但是,并不是药效分裂越精细越好。

过度拆分会使服务数量的扩张难以管理。因此,希望找到一种适合当前业务情况和团队成员技术水平的划分粒度。见https://time . geek bang . org/column/article/13891https://www . infoq.cn/article/2017/09/do-you-service-first。


本文关键词:从,单一应,单,一应,用到,服务,之前,微,服务,英皇体育

本文来源:英皇体育-www.ningpao.cn