微服务实践：全栈小团队“洪荒之力”改造阿里服务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），避免误用；流量控制，按服务分配流量，避免滥用。

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

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

微服务化团队实践

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

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

• 小而全团队（含UI，DEV，DATA，TEST）。

• 通过接口明确业务边界，无耦合（KISS or SRP）。

• War Room自治团队，对自己的业务负责。

• 做有生命的持续演进的产品或后台服务，不重要的项目关停并转。

• 对业务有使命感，不是打杂工，技术驱动业务。

• 不求完美，快速持续集成，弹性容错。

Behavior Driven Development

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

AI/IA as a Service

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

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

阿里小蜜技术体系

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

更多深度技术内容，请关注云栖社区微信公众号：yunqiinsight。