2017 年 10 月 22 日，又拍云 Open Talk 联合 Spring Cloud 中国社区成功举办了“进击的微服务实战派 —— Micro Service Open Talk 上海站”。本次活动共吸引来自爱奇艺、一号店、用友、京东等知名公司的 220 多位开发者参与、讨论。

本次活动特别邀请了拍拍信技术 VP 裴华，冰鉴科技信息技术部总监朱清，买单侠首席架构师、 复旦大学博士李荣陆，点融网架构师刘石明，大众点评研发许雪里五位嘉宾，就企业微服务架构实战展开深入浅出的分享与讨论。本文整理了 5 位讲师的精彩演讲。

微服务不能为了拆分而拆

拍拍信技术 VP 裴华就企业在进行微服务改造时会遇到的问题入手，从上级、同事对微服务改造的不理解，到微服务改造时需要注意的要点，介绍了拍拍信微服务改造实践。

在企业进行微服务改造时，经常会面临来自上级和其他部门的疑问与不理解：技术改造有什么用、技术改造时长多久、技术改造会影响项目进度和产品迭代吗？

裴华认为，微服务改造通常是由于系统发展存在困境，原有的系统无法适应之后的业务变化；在业务实施上存在问题，现有系统容易触发事故。在服务改造时，裴华建议通过短期计划和中长期计划相结合来降低技术改造对业务的影响，而且在企业进行微服务拆分时，需要控制微服务拆分的粒度，不能为了拆分而拆，并且独立出来的服务的逻辑要独立。

目前市面上常见的框架有 dubbo 和 dubbox，作为轻量级的微服务框架，可以和现有的 Spring 开发体系紧密结合，同时有足够的开源体系支持和供二次开发。

裴华详细介绍了微服务改造过程中需要注意的要点：

首先，是微服务改造需要实现的是整套完整的体系，微服务改造依赖于 Spring Cloud 生态体系，包含：服务中间件、网关系统、管理系统、监控体系、配置系统、发布系统；

其次，微服务生态体系必须逐步迭代完善，从小到大，从简到繁，保证生态体系每个阶段的产出都必须能够呈现，以及合理切分服务上线功能；

第三，生态系统服务切换不能影响业务进行，在业务切换的时候要合理规划设计服务切换方式，同时进行测试，确保业务功能和性能的正常。

此外，在微服务与非微服务的兼容过渡中需要注重人与系统的兼容。在系统中需要中间件（网关）、发布系统的支持，微服务调用和 httppclient 接口同时支持。

微服务实践“三部曲”

从 2016 年底开始，冰鉴信息技术部展开了对微服务架构的探索，并选择了 Spring Cloud 生态作为开启微服务应用系统建设的框架，期间经历了组件选型和业务上的重构。朱清在分享中通过对微服务架构庖丁解牛，层层分析了冰鉴科技在微服务实践中“三部曲”。

微服务的架构第一步是选择微服务构建的框架，冰鉴科技选择了 Spring Boot。 Spring Boot 可以使配置、部署、监控变得简单，在部署中可以实现一键启动，不需要预部署应用服务器，降低对运行环境的基本要求。

第二步是定制自己的 starter——组件脚手架，一般来说可以选择已有的 starters，在此基础上进行扩展，然后创建自动配置文件并设定 meta-inf/spring.factories 里的内容，发布 starters 即可。通过这个方法，业务系统开发人员可以直接引入新的 starter 进行开发，不需要关心使用的是什么组件。

第三步是部署传递数据的方式。有HTTP调用和异步消息两种方式。HTTP 调用：A 服务调用 B 服务 需要实时返回结果，调用方实时依赖执行结果的业务场景。异步消息：通过逻辑解耦和物理解耦的消息通信服务。这两种方式适用于数据驱动的任务依赖、用于传递任务执行完成的消息，并步用于传递输入输出数据。

攻克微服务的过程中遇到的问题

买单侠首席架构师李荣路通过对微服务管理与容器化实践的分享，阐述了进行微服务改造的原因，以及改造过程。

实现服务容器化主要是为了提供一致可复用的环境与提高服务的弹性伸缩，并且实现滚动发布、蓝绿发布。

李荣路分析了在实现微服务的过程中遇到的问题：微服务数量较多、测试工作量大，无法快速实现收益。

在节点和容器自动伸缩方面，存在只支持监控 CPU 和内存以及缩容时无法确定某个服务实例是否还在处理任务的问题。李荣路给出了建议：创建程序、用其他服务需要监控的指标，以及调用容器服务 API 进行扩容和缩容。

在实现监控时，只能监控到 CPU 和内存以及 IO、网络这几个方面，“这就需要在所有的基础镜像中加入 Zabbix Agent，使用 Zabbix 监控容器状态。”

同时容器内数无法持久化，日志也会成为一个问题。这时需要通过 stdout 输出日志，避免使用数据卷，一个应用对应一个 logstore，以便于搜索应用内的所有服务日志，然后需要在日志中打印上服务名称，便于在一个 logstore 搜索单个服务的日志。

运维可视化：所有人理解、执行、结果一致

点融网架构师刘石明认为通过运维可视化来表达结果，可视化后的自动化能让所有人理解一致、执行一致、结果一致。

企业在实现微服务需的运维系统包括：服务治理平台、网关规则管理、分布式 Trace 服务平台、第三方组件运维可视化平台、RabbitMq 的 Ops 管理以及缓存的 Ops 管理。基于 Spring Cloud 的点融网服务治理平台已经包含的服务有服务列表展示、API 鉴权、Health Check 检查、Swagger 文档库、服务依赖梳理。

在追踪每个请求的完整调用链路时，收集调用链路上每个服务的性能数据，方便开发者能够快速定位问题，通过对代码的零侵入，运用 JavaAgent 字节码增强技术，增加启动参数即可；同时基于 UDP 直接往 Collector 发送数据，少去了配置 Logback 、logstash 的繁琐，并且 UDP 传输不会对应用网络造成拥堵； Pinpoint 拥有丰富的 Plugin 库及良好的 Plugin 扩展。

分布式系统对任务调度的 6 点要求

大众点评研发许雪里以 XXL-JOB 为例阐述了分布式系统对任务调度的6点要求：一个轻量级分布式任务调度框架应该拥有 “HA、弹性扩缩、故障处理、阻塞处理、高性能、自运维”等特点，

XXL-JOB 作为一个轻量级分布式任务调度框架其核心部分包括：

• 调度模块（调度中心）：负责管理任务信息，触发任务执行，自身不承担业务逻辑；同时提供“日志、报表、告警、GLUE、注册中心”等功能；
• 执行模块（执行器）： 负责接收调度中心请求，进行任务逻辑执行、终止、日志加载等操作；专注于任务执行相关操作。

XXL-JOB 在 HA / 集群调度中心方面可以做到避免单点故障、发挥集群优势；在弹性扩缩方面可以适应业务快速发展；同时支持调度和任务解耦，全异步化；可以做到自助维护、实时监控、快速了解任务进展。