中台与微服务哪些事儿:一、不同客户微服务实践中的经验教训

一、客户在微服务化实践过程中遇到的问题(源自真实案例)

  1. 某跨国领军企业,以自上而下全新分析、设计为思路,以识别的业务对象为业务边界识别微服务,以重新开发、数据迁移做为手段实践微服务,发现依然无法达到1-2weeks持续交付的目标,不同领域部门质疑其方法的合理性。
  2. 某金融业客户,以SOA方法划分微服务粒度,以微服务框架做为实现手段,坚持保持传统需求管理、瀑布方法,结果出现开发版本依赖、构建依赖、上线依赖等现象严重。
  3. 某互联网公司,本想完全基于异步微服务实现,但由于分布式事务组件不具备、开发量大、大大影响开发、调度效率,不得不第一步先改为SOA方式才解决交付瓶颈。
  4. 某跨国领军企业,由于数据模型过于满足第三范式,导致数据模型无法解耦从而进一步进行有效的微服务切分,另在使用了微服务架构之后,发现性能反而下降。

二、为什么呢?

  1. 对于庞大复杂业务,按抽象的业务对象为业务边界是不够的,粒度过粗。
  2. 以SOA将微服务分层、团队之间也必然出现分层,架构依赖关系依然存大,微服务解耦是从业务到上线的垂直解耦,这是关键、关键、关键。传统需求管理喜欢搞大版本需求,业务业务边界没有按微服务范围解耦,需求人员没有解耦,没有建立独立演进的机制。
  3. 没有分布式事务组件、分布式跟踪平台、DevOps平台的支撑,微服务的开发、调试、运维就快不起来。
  4. 数据模型是微服务化的关键,属性未分层、未按分层拆表是无法微服务化的。

 

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值