OSC 第 113 期高手问答 -- 分布式服务框架

开源中国股瞎 发布于 2016/03/22 15:42
阅读 10K+
收藏 40

OSCHINA 本期高手问答(3月22日-3月28日) 我们请来了 @Nettying (李林锋)为大家解答关于分布式服务框架方面的问题。

 

@Nettying(李林锋),现任华为PaaS平台架构师,8Java NIO通信框架、平台中间件架构设计和开发经验,主导设计和开发的华为分布式服务框架已经在全球数十个国家成功商用。精通NettyMinaRPC框架、企业ESB总线、分布式服务框架等技术,《分布式服务框架原理与实践》、《Netty权威指南》作者,公司总裁技术创新奖获得者。

微博、微信:Nettying

微信公众号:Netty之家

“微服务”无疑是本年度最热的技术关键词之一!近些年来,越来越多网站需要同时提供Web、移动AppOpenAPI多种访问方式,基于分布式服务的业务分治与复用需求越来越强烈,使用分布式服务构建系统已经成为互联网开发的常用手段。但是分布式服务的关键技术有哪些?核心原理是什么?最佳实践是什么?如何落地微服务呢?

为了鼓励踊跃提问,@博文视点 会在问答结束后从提问者中抽取 5 名幸运会员赠予

《分布式服务框架原理与实践》一书。

    

购买链接:http://item.jd.com/11870213.html

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就分布式服务框架方面问题向 @Nettying 提问,请直接回帖提问。

加载中
0
ilovej
ilovej
@Nettying :分布式服务中的事务怎么处理,互联网公司选择哪个开源的框架比较好?
zhangqi94
zhangqi94
通过Paxos协议实现分布式事务么??用消息中间件做分布式会不会存在消息重复,丢失,延迟等问题啊
Nettying
Nettying
分布式服务中的服务通常有如下几类:1) 幂等性服务,不涉及事务一致性;2)强事务一致性,主要跟金额相关,例如充值、转账类服务;3)最终一致性服务,可以容忍一定时间周期的短暂不一致性,最终通过事务补偿等机制解决。 大部分与事务一致性相关的都建议采用最终一致性方案,通常会使用消息中间件来实现,例如阿里的Notify。 还有少部分要求强一致性,建议通过TCC二阶段提交等机制解决。
0
newzai
newzai
@Nettying 2个微服务直接的关系,可以像对象直接的关系那样,做到多对多吗?如何实现2个服务直接的多对多关系。
newzai
newzai
我的意思是微服务之间也会设计调用关系,如何解决他们直接的关系
Nettying
Nettying
微服务之间的关系就是N个消费者调用1个服务的关系,跟对象之间的关系不是同一个维度,不能这样类比
0
精通吹水
精通吹水
@Nettying : 微服务,核心思想应该是kiss原则,每个服务足够简单,依赖少。通过一定的手段保证各个服务正常运行动态增加,就是运维简单。
Nettying
Nettying
是的。
0
hzh62
hzh62
@Nettying :分布式服务的监控室直接设计在服务框架里面,还是外挂功能模块。分布式系统里面的控制中心如何保证服务高可用性,是否考虑 hbase 里面的 master,使用了 HQuorumPeer来控制,
Nettying
Nettying
分布式服务的监控的通常实现如下: 1)服务节点Host或者VM安装运维Agent,负责分布式监控和性能数据采集; 2)汇总和分析节点负责从Agent拉去或者定期采集性能KPI数据做运维和告警。
0
西夏一品堂
西夏一品堂
求推荐一个成熟的分布式,跨语言的RPC框架,dubbo是很成熟,强大,但是不跨语言,thrift有点底层,还有很多东西需要自己写,也没有监控
Nettying
Nettying
建议gRPC,不过监控和运维需要自己补齐,可以考虑使用开源的监控框架,例如Zabbix等
0
brothong
brothong
@Nettying :一般多大规模的生产环境才有必要上分布式?怎样部署?
Nettying
Nettying
这个没有标准,通常当你的单体架构严重制约 新业务的快速开发、部署和升级的时候,就要考虑做服务化改造和分布式部署
0
Gondar
Gondar

引用来自“西夏一品堂”的评论

求推荐一个成熟的分布式,跨语言的RPC框架,dubbo是很成熟,强大,但是不跨语言,thrift有点底层,还有很多东西需要自己写,也没有监控
头一次听到或 dubbo 很成熟。。。都有谁用了ali开源的dubbo
Gondar
Gondar
回复 @Nettying : GRPC目前还不够成熟,但是给他点时间,就没thrift之类的什么事了。
Nettying
Nettying
推荐谷歌的gRPC
海空
海空
dubbox吧.
Gondar
Gondar
回复 @-赵本山- : 就算要上dubbo,也是上dubbox啊。。。
稻草鸟人
稻草鸟人
回复 @-赵本山- : dubbo 用到哪些业务?
下一页
0
六点小巷
六点小巷
@Nettying :分布式缓存和消息概述一下,书里面有涉及吗
Nettying
Nettying
木有,主要讲的是分布式服务框架
0
Tom-Lin
Tom-Lin
在实际情况下,如果大量使用微服务来对系统开发,那么微服务之间的通信会不会成为系统瓶颈?如何决定每个微服务的粒度的大小?
Nettying
Nettying
会的,这取决于两点: 1)服务框架或者RPC的性能; 2)业务的使用方式,例如传输的POJO对象大小等。 微服务的划分原则通常是 小,且只干一件事情。 举例,订单的增删改查就可以划分为订单管理服务
0
祥子-匠心
祥子-匠心
@Nettying老师,你好!项目什么时候开始考虑分布式或微服务比较合适?新项目是否已开始就使用分布式?比如在初创公司,在用户和技术人员较少的时候,分布式是否会增加维护成本?
Liujue
Liujue
回复 @海空 :
debuglife
debuglife
回复 @海空 : 所言不虚
CheckStyle
CheckStyle
回复 @Nettying : 诚然诚然。一开始,都是做一个monolithic的系统,后面再逐步演进成micro service。我一向的做法
Nettying
Nettying
通常在项目初期,业务比较简单,没有必要引入分布式服务框架;当业务代码量膨胀,单体架构的弊端逐步显现出来之后。可以根据业务的发展状况和需求,以及人员技能匹配等角度评估之后,引入分布式服务框架和微服务实践。
海空
海空
我觉得就是看菜吃饭. 架构是一步步改出来的. 不需要一口气高的高大上. 大量精力都投入到技术上. 得不偿失.
返回顶部
顶部