微服务实践:全栈小团队“洪荒之力”改造阿里服务CRM技术体系

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 8月9日2016云栖大会北京峰会拉开帷幕,阿里高级技术专家肥侠带来了“智能客服:基于微服务的系统改造实践”的重要演讲。其中首先进行了业务介绍,接着和大家简单分享了微服务,着重和大家讲述了微服务的实践,包括微服务技术实践、微服务团队实践、DT下的微服务。精彩不容错过——
本文不重点介绍业务系统,更偏重于经验分享。首先进行了业务介绍,接着和大家简单分享了微服务,着重和大家讲述了微服务的实践,包括微服务技术实践、微服务团队实践、DT下的微服务。

以下为内容整理:


作为全球最大的电商平台,阿里巴巴面对的是逾4亿的活跃消费者、上千万的活跃商家、几千种阿里自有产品和业务,以及每天上千万笔的交易。从这些天然交易闭环里,有极其丰富的数据,如何用技术来实现用户的“One-Click”和“One-Stop”的服务体验?

通过微服务架构的应用,我们重构了原来臃肿低效的CRM系统,让每个服务小团队专注自己的业务快速迭代。同时,通过数据、模型、机器学习等智能技术手段构建全新的后台微服务,极大的扩展了我们平台的服务吞吐能力,即使在双十一的特殊场景下,利用非常有限的人力,也完美承接了当天上千万消费者的服务诉求和几亿消息的发送。

 

挑战

我们的业务变化非常快,从最初的简单的CRM,到现在要面对很多端很多业务,需求变化很快, 服务规模指数级增长,服务渠道需求多元化,服务内容随着业务进一步复杂,服务体验的标准不断提升,开发团队的压力也很大,对应的挑战就会很大。

我们希望做到“两个One”,OneStopOneClick,可以让不同的业务方和商家快速接入我们的系统,也可以让我们的“小二”快速的解决用户问题。

7d146c86caf697674c677a8cb01b260a5739d6b0

大概的业务背景会分成三个层次。包括用户进来提问会根据用户问题做智能路由,我们会有智能机器人以人机交互的方式去解决简单的问题,复杂问题则会根据场景智能分配给最合适的客服小二处理,同时会有一个后台的管理系统,包括快速接入、现场管理、绩效业绩。

一个孤立系统的总混乱度会不断增加。业务飞速发展让系统应接不暇,随之而来的噩梦也会越来越多,开发效率低、跟不上业务发展、稳定性差、代码维护难等等,我们希望用微服务的方式把这个系统做改造升级。

 

微服务化实践

设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。

微服务架构要求

  • 分布式服务组成的系统
  • 强服务个体和弱通信总线去中心化治理(SOA
  • 去中心化数据依赖
  • 自动化运维(DevOps
  • 容错
  • 按照业务而不是技术来划分组织
  • 做有生命的产品而不是项目
  • 快速演化

我们是逐步演进的,最早是一个大而全的CRM,最初为ORM+MVC。随着业务发展的越来越快,我们开始用RPC,利用集团的分布式技术中间件快速解决了微服务技术上的挑战。RPC与接下来的MSA界限已经非常小了,更重要的团队的管理理念,按微服务化的理念来拆分团队和系统,让分工和开发效率更加高效。现在,我们不仅仅用Java和项目去做服务,我们用离线数据、机器学习来驱动我们的整个系统和业务的发展。我们通过Service的包装把后台的离线数据也暴露给系统去用,去开发所谓的智能的CRM

95569e9d847f27a5366c3e6efea707bed73c6cb7


微服务化技术实践

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

基于React的插件化方案

f639e3d601232b408835ffa998ce7f5a5c0bfd5c

我们不仅把后台服务拆分,前端基于React把所有的模块分成一个个小App,这些小App可以自己去开发,只要按照前端的规范,开发之后可以嵌到我们的CRM当中,这样在前端就把所有的系统去解耦了。

服务发现

4cfdfd90f661b29b6ceee6de83b906e7a2742317

服务发现会分成两种模式。小型公司没有那么多服务和应用,一般通过LoadBalancer做服务治理,用户访问的应用和后台的服务都是透明的;大规模互联网公司一般则通过客户端做服务治理,所有的业务逻辑、服务治理在每个微服务后台都会有一个客户端去把自己的信息注册上去,前台服务在访问时就通过服务注册去寻找信息,如果后台服务挂了,它也会告诉服务注册,前台就会知道这个服务不可用。通过这种方式可以实现流控、负载均衡等。

服务间通信(IPC

b60a0eaa4eba9193ad2d32198ccdc896039a74a8

我们希望所有的服务能够内聚,服务之间是非常轻量级的,不要耦合在一起。通过这样的沟通方式有:

  • 同步异步调用(HTTP/RPC):RESTThriftDubbo
  • 异步消息(Notification/PubSub):RabitMQKafka MetaQNotify

保证可用性

  • 怀疑第三方:有兜底,制定好业务降级方案;遵循快速失败原则,一定要设置超时时间;适当保护第三方,慎重选择重试机制。
  • 防备使用方:设计一个好的apiRPCRestful),避免误用;流量控制,按服务分配流量,避免滥用。
  • 做好自己:单一职责原则;控制资源的使用;避免单点。

 

微服务虽然开发简单,技术栈灵活,服务独立无依赖,独立按需扩展,可用性高,但微服务是有维护成本的,数据的一致性、性能的监控、多服务运维、系统部署依赖等问题想要都解决掉是不容易的。处于不同阶段的技术团队,需要根据自己公司的技术积累和团队的技术水平做相应的选择。

 

微服务化团队实践

技术对于微服务来说从来都不是最重要的,大部分人很快就能实现设计微服务架构,理念上的转变和团队的管理上才是最大的挑战。 那么怎样去建设微服务团队呢?

 

微服务团队应该按照业务组织资源,建立全栈小团队。

  • 小而全团队(含UIDEVDATATEST)。
  • 通过接口明确业务边界,无耦合(KISS  or SRP)。
  • War Room自治团队,对自己的业务负责。
  • 做有生命的持续演进的产品或后台服务,不重要的项目关停并转。
  • 对业务有使命感,不是打杂工,技术驱动业务。
  • 不求完美,快速持续集成,弹性容错。

Behavior Driven Development

52f6ab9db98d23dcc2613395049c48bc636ee3c3

BDD从业务的维度,让PD、业务方、开发和测试能达成一致,知道要做的事情是什么,通过敏捷开发方式定义出来story,把整个复杂的PRD拆分成很小的容易理解的,然后测试人员和开发人员针对这些story去写业务用例,这个用例不仅能做持续集成,也能变成文档交接。

 

AI/IA as a Service

DT时代下的产品开发,基于经验积累的工程能力变的不那么重要,而基于大数据和机器学习沉淀的模型算法变成越来越重要。未来的微服务不仅仅是Java或者工程师开发出来的,而是越来越多的由机器从海量的数据当中学习出来,他们也是我们系统自治的提供微服务的重要组成。

7e3ed2c376a6474c32c70b3948f170542a6fd847

我们自己维护的专业的数据库、从客户那边积累下的数据库和网络上的非结构化的数据都拉下来去做对应的数据清洗和拟合,把这些离线数据封装出来的模型以Java服务(API)的方式暴露出来,变成我们应用的一部分。

阿里小蜜技术体系

b317a763e4763ab558ee80d8bf8c2aa414f005a9

图为阿里小蜜问答系统,我们把数据做一些自然语言的处理后,能够智能回答用户的一些简单问题,提供越来越真实和自然的人机交互。比如可以通过多轮交互的方式,更准确的理解用户语意和真实意图,再通过知识图谱的构建来帮助用户快速的找到准确的答案。

相关文章
|
6天前
|
API 持续交付 开发者
后端开发中的微服务架构实践与挑战
在数字化时代,后端服务的构建和管理变得日益复杂。本文将深入探讨微服务架构在后端开发中的应用,分析其在提高系统可扩展性、灵活性和可维护性方面的优势,同时讨论实施微服务时面临的挑战,如服务拆分、数据一致性和部署复杂性等。通过实际案例分析,本文旨在为开发者提供微服务架构的实用见解和解决策略。
|
7天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
2天前
|
消息中间件 设计模式 运维
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在现代后端开发中的应用,通过实际案例分析,揭示了其在提升系统灵活性、可扩展性及促进技术创新方面的显著优势。同时,文章也未回避微服务实施过程中面临的挑战,如服务间通信复杂性、数据一致性保障及部署运维难度增加等问题,并基于实践经验提出了一系列应对策略,为开发者在构建高效、稳定的微服务平台时提供有价值的参考。 ####
|
2天前
|
消息中间件 监控 数据管理
后端开发中的微服务架构实践与挑战####
【10月更文挑战第29天】 在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用程序的首选方案。本文探讨了微服务架构的核心概念、实施策略以及面临的主要挑战,旨在为开发者提供一份实用的指南,帮助他们在项目中成功应用微服务架构。通过具体案例分析,我们将深入了解如何克服服务划分、数据管理、通信机制等关键问题,以实现系统的高可用性和高性能。 --- ###
21 2
|
4天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
|
8天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
7天前
|
设计模式 人工智能 API
后端开发中的微服务架构实践与挑战#### 一、
本文将深入浅出地探讨微服务架构在后端开发中的应用实践,分析其带来的优势与面临的挑战。通过具体案例,展示如何有效地构建、部署和管理微服务,旨在为读者提供一份实用的微服务架构实施指南。 #### 二、
|
3月前
|
搜索推荐
实现CRM与ERP系统无缝集成,优化客户关系管理
在当今竞争激烈的市场环境中,企业要想保持领先地位,必须高效地管理客户关系并优化内部资源。CRM(客户关系管理)系统与ERP(企业资源规划)系统的无缝集成,为企业提供了一种强大的工具,以实现这一目标
63 2
|
3月前
|
监控 搜索推荐 数据管理
crm客户管理系统来帮助企业管理和提高运营效率
crm系统帮助企业简化销售流程,提高工作效率。CRM 客户管理系统确实能够在多个方面帮助企业管理和提高运营效率,具体表现如下:
33 3
|
4月前
|
监控 数据挖掘 数据安全/隐私保护
ERP系统中的客户关系管理(CRM)
【7月更文挑战第25天】 ERP系统中的客户关系管理(CRM)
350 3