0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

微服务架构多微才合适

lhl545545 来源:电子发烧友网 2018-02-07 17:14 次阅读

一、互联网架构为什么要进行服务化-总结

上一篇和大伙交流了一下,随着数据量、并发量、业务复杂度的增长,互联网架构会出现以下问题:

(1)代码到处拷贝

(2)底层复杂性扩散

(3)基础库(so/jar/dll)耦合

(4)SQL质量得不到保障,业务相互影响

(5)数据库耦合

“服务化”是一个很好的解决上述痛点的方案。

服务化之后,可能会引发分布式事务的问题,“没人愿意引入分布式事务,当基于业务水平拆分的时候,要业务专家介入,合理拆分服务化,以后就服务内高内聚,事务可以保证,对于夸服务调用,通过补偿等手段,只要最终一致性就行,毕竟连现在的银行转账都不是强一致性。”

分布式事务是业界没有彻底解决的难题,任何架构设计都是一个折衷,吞吐量?时延?一致性?哪个是主要矛盾,优先解决哪个问题。大数据、高并发、业务复杂性是主要矛盾的时候,或许“最终一致性”是一个替代“事务”更好的,或者说业务能够接受的方案。

多了一层服务层,架构实际上是更复杂了,需要引入一系列机制对服务进行管理,RPC服务化中需要注意:

(1)RPC服务超时,服务调用者应有一些应对策略,比如重发

(2)关键服务例如支付,要注意幂等性,因为重发会导致重复操作

(3)多服务要考虑并发操作,相当单服务的锁机制比如JAVA中的synchronized

二、互联网微服务架构多“微”才适合

大家也都认可,随着数据量、流量、业务复杂度的提升,服务化架构是架构演进中的必由之路,今天要讨论的话题是:微服务架构多“微”才合适?

【粗粒度:一个服务层】

微服务架构多微才合适

最粗犷的玩法,所有基础数据的访问,都通过一个service访问,在业务不是特别复杂的时候还好,一旦业务变复杂了,这个service层会变得非常重,成为耦合点之一,以微信场景为例,假设有一个通用的服务层来访问基础数据,这个服务层可能是这样的:

微服务架构多微才合适

有一个统一的service层,用户信息,好友信息,群组信息,消息信息都通过这个service层来走。

细节:微信单对单消息是一个写多读少的业务,故没有缓存。

【一个子业务一个service】

如果所有的信息存储都在一个service里,那么一个地方出bug,就将影响整个业务,所以更合理的做法是在服务层进行细分,架构如何细分?垂直拆分是个好的方案,将子业务一个个拆出来,那么微信的服务化架构或许会变成这个样子:

微服务架构多微才合适

(1)用户相关的子业务有user-service

(2)好友相关的子业务有friend-service

(3)群组相关的子业务有group-service

(4)消息相关的子业务有msg-service

这样的话,一个service出问题也不会影响其他service,同时数据层也按照业务垂直拆分开了。

服务粒度变细之后,出现一个新的问题,业务与服务的连接关系变复杂了,有什么好的优化方案么?

微服务架构多微才合适

常见的,加入一个高可用服务分发层集群,并在协议设计时加入服务号,可以减少蜘蛛网状的依赖关系:

(1)调用方依赖分发层,传入服务号

(2)分发层依赖服务层,通过服务号参数分发

【一个数据库对应一个service】

数据访问service最初是从DAO/ORM的数据访问需求过来的,所以有些公司也有一个数据表一个service的玩法。

一个子业务对应一个service的玩法是:

微服务架构多微才合适

(1)服务层,整个群业务是一个service

(2)存储层,实际可能对应了群信息、群成员、群消息等多个数据表

拆分成一个数据表一个service,则架构会变成这样:

微服务架构多微才合适

群信息表,群成员表,群消息表等各个数据表之间也解耦开了,不会相互影响了。

【一个接口对应一个service】

微服务架构中更极端的,甚至一个接口对应一个微服务,这样的话,架构就从:

微服务架构多微才合适

(1)修改群信息服务

(2)增加群信息服务

(3)获取群信息服务

多个服务操纵同一个数据表,使用同一片缓存,每个接口出问题,都不会影响其他接口。

三、粒度粗细的优劣

上文中谈到的服务化与微服务,不同粒度的服务化各有什么优劣呢?

总的来说,细粒度拆分的优点有:

(1)服务都能够独立部署

(2)扩容和缩容方便,有利于提高资源利用率

(3)拆得越细,耦合相对会减小

(4)拆得越细,容错相对会更好,一个服务出问题不影响其他服务

(5)扩展性更好

(6)…

细粒度拆分的不足也很明显:

(1)拆得越细,系统越复杂

(2)系统之间的依赖关系也更复杂

(3)运维复杂度提升

(4)监控更加复杂

(5)出问题时定位问题更难

(6)…

关于微服务架构的“粒度”问题,以及各粒度的优劣,大伙有什么好的看法,欢迎补充,建设性的意见将在后续文中和大伙share。

四、结束的话

聊了许多,有网友问,笔者对待服务化以及微服务粒度的看法,个人觉得,以“子业务系统”粒度作为微服务的单位是比较合适的:

微服务架构多微才合适

末了,讨论完微服务架构的粒度,后续文章和大家聊一聊微服务的最佳实践,需要什么样的框架、组件、技术能够将服务化在较短的时间内开展起来,下周和大伙再聊。

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 微服务
    +关注

    关注

    0

    文章

    131

    浏览量

    7321
收藏 人收藏

    评论

    相关推荐

    架构与设计 常见微服务分层架构的区别和落地实践

    架构风格越倾向于清晰的职责定位,且让领域模型成为架构的核心。 基于这些架构风格,在软件架构设计过程中又有非常
    的头像 发表于 10-22 15:34 104次阅读
    <b class='flag-5'>架构</b>与设计 常见<b class='flag-5'>微服务</b>分层<b class='flag-5'>架构</b>的区别和落地实践

    微服务架构与容器云的关系与区别

    微服务架构与容器云密切相关又有所区别。微服务将大型应用拆分为小型、独立的服务,而容器云基于容器技术,为微服务提供构建、发布和运行的平台。区别
    的头像 发表于 10-21 17:28 126次阅读

    入门级攻略:如何容器化部署微服务

    第一步理解容器化基础,第二步创建Dockerfile,第三步构建推送镜像,第四步部署微服务,第五步管理微服务、第六步优化更新。容器化部署微服务是现代软件开发中的一种高效方法,可提供良好的可移植性、可扩展性和管理性。容器化部署
    的头像 发表于 10-09 10:08 89次阅读

    Proxyless的活流量和微服务治理

    1. 引言 1.1 项目的背景及意义 在当今的微服务架构中,应用程序通常被拆分成多个独立的服务,这些服务通过网络进行通信。这种架构的优势在于
    的头像 发表于 08-28 16:54 1502次阅读
    Proxyless的<b class='flag-5'>多</b>活流量和<b class='flag-5'>微服务</b>治理

    NVIDIA NIM微服务带来巨大优势

    服务通过热门 AI 模型为数百万开发者带来高达 5 倍的 token 效率提升,使他们能够立即访问在 NVIDIA DGX Cloud 上运行的 NIM 微服务
    的头像 发表于 08-23 15:20 415次阅读

    采用OpenUSD和NVIDIA NIM微服务创建精准品牌视觉

    全球领先的创意和制作服务机构率先采用 OpenUSD 和 NVIDIA NIM 微服务来创建精准的品牌视觉。
    的头像 发表于 08-01 14:33 369次阅读

    【算能RADXA微服务器试用体验】Radxa Fogwise 1684X Mini 规格

    通过网络可以了解到,算能RADXA微服务器的具体规格: 处理器:BM1684X 算力:高达32Tops INT8峰值算力 内存:16GB LPDDR4X 内存 存储:64GB eMMC 编程框架
    发表于 02-28 11:21

    Java微服务随机掉线排查过程简析

    我们的业务共使用 11 台(阿里云)服务器,使用 SpringcloudAlibaba 构建微服务集群, 共计 60 个微服务, 全部注册在同一个 Nacos 集群。
    的头像 发表于 01-13 17:41 877次阅读
    Java<b class='flag-5'>微服务</b>随机掉线排查过程简析

    gpu服务器评测

    GPU服务器进行评测。 一、超GPU服务器概述 超GPU服务器是一种基于超
    的头像 发表于 01-10 10:37 1191次阅读

    游戏公司不使用微服务架构的原因

    微服务基本只有 request/response 的模式。做不了 streaming?微服务通常要求应用是无状态的才能做到水平扩展。streaming 本身就是加入了状态
    的头像 发表于 12-29 11:18 396次阅读

    如何搭建微服务架构的全局图景

    如果一直保持共用数据库的模式,则整个架构会越来越僵化,失去了微服务架构的意义。因此小明和小红一鼓作气,把数据库也拆分了。所有持久化层相互隔离,由各个服务自己负责。另外,为了提高系统的实
    的头像 发表于 12-27 15:16 450次阅读
    如何搭建<b class='flag-5'>微服务</b><b class='flag-5'>架构</b>的全局图景

    如何构建弹性、高可用的微服务

    基于微服务的应用程序可实现战略性数字转型和云迁移计划,对于开发团队来说,这种架构十分重要。那么,如何来构建弹性、高可用的微服务呢?RedisEnterprise给出了一个完美的方案。文况速览
    的头像 发表于 11-26 08:06 433次阅读
    如何构建弹性、高可用的<b class='flag-5'>微服务</b>?

    设计微服务架构的原则

    微服务是一种软件架构策略,有利于改善整体性能和可扩展性。你可能会想,我的团队需不需要采用微服务,设计微服务架构有哪些原则?本文会给你一些灵感
    的头像 发表于 11-26 08:05 531次阅读
    设计<b class='flag-5'>微服务</b><b class='flag-5'>架构</b>的原则

    docker微服务架构实战

    随着云计算和容器化技术的快速发展,微服务架构在软件开发领域中变得越来越流行。微服务架构将一个大型的软件应用拆分成多个小型的、独立部署的服务
    的头像 发表于 11-23 09:26 601次阅读

    springcloud微服务架构

    Spring Cloud是一个开源的微服务架构框架,它提供了一系列工具和组件,用于构建和管理分布式系统中的微服务。它基于Spring框架,旨在通过简化开发过程和降低系统复杂性来帮助开发人员构建弹性
    的头像 发表于 11-23 09:24 1118次阅读