全栈小团队改造阿里服务CRM技术体系

本文不重点介绍业务系统，更偏重于经验分享。首先进行了业务介绍，接着和大家简单分享了微服务，着重和大家讲述了微服务的实践，包括微服务技术实践、微服务团队实践、DT下的微服务。

以下为内容整理：

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

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

挑战

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

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

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

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

微服务化实践

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

微服务架构要求

分布式服务组成的系统

强服务个体和弱通信总线去中心化治理（SOA）

去中心化数据依赖

自动化运维（DevOps）

容错

按照业务而不是技术来划分组织

做有生命的产品而不是项目

快速演化

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

微服务化技术实践

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

基于React的插件化方案

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

服务发现

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

服务间通信（IPC）

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

同步异步调用（HTTP/RPC）：REST，Thrift，Dubbo。

异步消息（Notification/PubSub）：RabitMQ，Kafka，MetaQ，Notify。

保证可用性

怀疑第三方：有兜底，制定好业务降级方案；遵循快速失败原则，一定要设置超时时间；适当保护第三方，慎重选择重试机制。

防备使用方：设计一个好的api（RPC、Restful），避免误用；流量控制，按服务分配流量，避免滥用。

做好自己：单一职责原则；控制资源的使用；避免单点。

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