Apache Dubbo 开发者沙龙「广州站」直播报名中!

主播:amber涂南 视频数:16
4167
直播介绍 相关视频
#微服务# #dubbo# #Sentinel# #Nacos#

Dubbo 诞生于 2008 年,是阿里巴巴开源的高性能分布式服务框架(A High Performance Java RPC Framework),使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring 框架无缝集成。

Dubbo 于 2018 年成为 Apache 基金会孵化项目。

2019 年,Apache Dubbo 开发者沙龙继续前行,将新一年的首站定在了羊城广州。沙龙嘉宾阵容不仅延续了以往的高水准,我们在当天早上将首次开展小型的见面会,邀请 Dubbo 用户、社区核心成员面对面,一起坐下来聊聊社区发展的那些事儿。

线下活动报名

如果您没法亲临现场,您还可以点这里-> 参与调研,我们将筛选 5 名认真填写表单的同学,送出价值 99 元的《码出高效,Java开发手册》(1-19 活动结束后统一寄出)

钉钉搜索群号:21973601,加入 Apache Dubbo 开源讨论群

EDM_12_25_

该直播其他视频
  • 【Dubbo 开发者日上海站】这可能是微服务开发者们最关注的技术盛宴
    【Dubbo 开发者日上海站】这可能是微服务开发者们最关注的技术盛宴
    来源:amber涂南 3840
  • 【报名中!Dubbo 开发者日】这可能成为微服务最关注的技术盛宴
    【报名中!Dubbo 开发者日】这可能成为微服务最关注的技术盛宴
    来源:amber涂南 8060
  • 联合 CNCF 共同出品:Kubernetes and Cloud Native Meetup 上海站
    联合 CNCF 共同出品:Kubernetes and Cloud Native Meetup 上海站
    来源:amber涂南 3960
  • 微服务发现与治理 | Nacos 技术沙龙杭州站
    微服务发现与治理 | Nacos 技术沙龙杭州站
    来源:amber涂南 6470
您可能感兴趣
  • 【报名中!Dubbo 开发者日】这可能成为微服务最关注的技术盛宴
    【报名中!Dubbo 开发者日】这可能成为微服务最关注的技术盛宴
    来源:amber涂南 8060
  • 【Dubbo 开发者日上海站】这可能是微服务开发者们最关注的技术盛宴
    【Dubbo 开发者日上海站】这可能是微服务开发者们最关注的技术盛宴
    来源:amber涂南 3840
  • 【Dubbo开发者日上海站】这可能是微服务开发者们最关注的技术盛宴
    【Dubbo开发者日上海站】这可能是微服务开发者们最关注的技术盛宴
    来源:社区助手 3330
问答
1618424704827062 | 7月前 在对复杂的业务系统进行微服务的拆分时应该注意什么
回答
  • 微服务总体划分原则: • 业务领域拆分:以客户业务方为输入 • 参考概要设计文档(如有) • 高内聚、低耦合原则 • 服务中心内的业务关联性很高 • 服务中心之间的隔离性比较大 • 业务可运营性原则 • 承载业务逻辑、沉淀业务数据、产生业务价值 • 服务颗粒度原则 • 功能完整性、职责单一性 • 服务粒度适中,团队可接受 • 伸缩需求拆分原则 • 以用户体验为最高优先,针对突出的高访问业务,可独立拆分服务 • 渐进性的建设原则 • 迭代演进,不要一次拆分过细,否则落地实施会有数据库性能和分布式事务问题 • 故障隔离拆分 • 服务不稳定、或可控度不高的服务(比如第三方服务带来的不可控和故障),可以考虑独立拆分降低风险 • 同一个领域不要拆分 • 曾经阿里曾经把天猫评价和淘宝评价拆成两个,导致两套数据源,需要两套开发人员开发,切做数据统计时,非常麻烦,最后又合成一个服务单元。
  • 微服务要如何拆分,是否拆分粒度越小越好?一般情况下,对于服务的拆分并非越小越好,甚至极端的案例是把一块功能拆分成一个服务,这种做法是不对的。因此,拆分粒度应该保证微服务具有业务的独立性与完整性,服务的拆分围绕业务模块进行拆分。例如将 VR 资讯系统进行服务拆分,分为资讯系统、话题系统、日报系统、百科系统四个微服务系统。 但是,很多情况下,服务的拆分围绕业务模块进行拆分是一种理想状态下的拆分方法,换句话说,我们在架构设计之初就假定我们可以掌握一切。然而,不同的服务可能由不同的团队开发与维护,实际场景下,微服务的便利性更多的在于团队内部能够产生闭环,换句话说,团队内部可以易于开发与维护,便于沟通与协作,但是对于外部团队就存在很大的沟通成本与协作成本。现在,我们来看一个案例。团队 A 考虑到功能的复用性而开发了一个“互动组件”,其中包括 “评论模块”功能。此时,团队 B 并不知情也开发了一个类似的“互动组件”。而团队 C 也有这个需求,它知道团队 A 有这个“互动组件”,希望可以复用,但是由于这个“互动组件”在设计的时候更多地考虑了团队 A 的当前业务,没有很好的复用性,例如不支持“评论盖楼”功能,而由于团队 A 出于当前其他项目的进度原因无法马上提供支持,团队 B 评估后决定花一周时间自己开发一个符合自己业务需求的“互动组件”。此时,各个项目团队各自维护了一个“互动组件”。此外,我们再来看一个案例。一个 OA 系统拥有“用户管理”、“文件管理”、“公告管理”、“政策管理”、“公文管理”、“任务管理”、“审批管理”等功能,如果按照微服务架构思想可以围绕业务模块进行拆分,但是事实上这个 OA 系统的最终用户只有 30 多人,使用微服务架构可能有点“杀鸡用牛刀”的感觉了。回顾下,第一个案例中,由于团队之间的职责与边界导致了服务的复用存在局限性,甚至造成各自为战的局面,这种情况一般需要公司层面进行规划和统筹。第二案例中,由于用户量不大,系统也不复杂,使用微服务反而带来了不必要的设计和运维难度,同时也带来了一些技术的复杂度。此外,我们还需要考虑服务依赖,链式调用、数据一致性、分布式事务等问题。 总结下,服务的拆分是一个非常有学问的技术活,要围绕业务模块进行拆分,拆分粒度应该保证微服务具有业务的独立性与完整性,尽可能少的存在服务依赖,链式调用。但是,在实际开发过程中,有的时候单体架构更加适合当前的项目。实际上,微服务的设计并不是一蹴而就的,它是一个设计与反馈过程。因此,我们在设计之初可以将服务的粒度设计的大一些,并考虑其可扩展性,随着业务的发展,进行动态地拆分也是一个不错的选择。 原文地址:http://blog.720ui.com/2017/msa_design/
  • 路过
展开全部答案
1784847875220323 | 7月前 特别卡,报名了线程,下午有事情去不了了,可惜了
回答
中间件小哥 | 7月前 关注“阿里巴巴中间件”微信公众号,发送“中间件”,参与第一轮线上抽奖活动。
回答
发送
提问 0/100