UDN-企业互联网技术人气社区

板块导航

浏览  : 1691
回复  : 0

[干货] 《电商 CRM 的微服务重构实践》

[复制链接]
呵呵燕的头像 楼主
  阿里巴巴高级技术专家介绍微服务系统改造的实践

  介绍了单体应用CRM带来的痛苦,决定使用微服务。

  观点:微服务不是万能的,微服务实施的前提是系统复杂,在业务发展初期可以用单体应用优先满足业务需求。

  介绍了M Flower对微服务的定义: > The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

  提到了康威法则:组织内的沟通结构决定系统设计结构,并延伸出其他概念: - 沟通成本随人力增加呈指数增加 - 你不能把事情做的完美,但是可以把事情完成,构建有生命力的系统,而不是完美的系统,持续集成。问题太复杂就忽略细节,资源不够就减少功能。瀑布式开发。 - 人的沟通协调能力有上限。 - 组织决定架构。

  微服务的目的是有效的拆分应用,实现敏捷开发和部署。

  服务间协作:两种方式, - 请求响应模式,REST RPC - 异步消息模式:MQ KAFKA

  服务治理:去中心化治理, - ZOOKEPPER - HSF(client) - AWS Elastic Load Balancer(server)

  微服务的优点: - 开发简单 - 技术栈灵活 - 服务独立无依赖 - 扩展性强 - 可用性高 - 微服务的缺点: - 多服务运维难度 - 部署依赖 - 通信成本 - 数据一致性 - 集成测试 - 重复工作 - 性能监控

  容错方案 怀疑第三方: - 降级方案 - 快速失败 - 熔断和重试 - 故障模拟 防备使用方: - 规范API,提供文档,避免吴用 - 流量控制降级 做好自己: - 单一职责原则(SRP)

  微服务决策推导

2.png


  持续集成交付和容错

  允许分布式系统存在缺项,通过不断增强系统能力来提升系统可靠性,而不是在设计之初就避免系统缺陷。

  按业务划分服务,组织研发资源

  数据闭环

1.png


原文作者:佚名  来源:开发者头条

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部