内容来源：2017年4月22日，练海荣在“【沪江技术沙龙】 -- 漫谈微服务架构实践”进行《如何支撑微服务架构落地》演讲分享。IT大咖说作为独家视频合作方，经主办方和讲者审阅授权发布。

编辑：IT大咖说阅读字数：2265

摘要

如今微服务如日中天，优势和弊端也有各种描述，那么我们是否应该采用微服务架构？如何规避微服务的弊端，放大微服务优势？如何在先进性和实用性中作出平衡，顺利落地？

嘉宾演讲视频地址：http://t.cn/RKJFQLZ

什么是微服务架构？

微服务 ≈ 模块化开发 + 分布式计算

微服务架构带来的好处

我认为微服务架构带来了两个好处。第一个好处就是降低了系统的复杂度，第二个是提升了我们的开发效率。

前一段时间我们在决定来做微服务架构的过程中做了很多的调研。

微服务看起来很好，有没有给团队带来麻烦？

微服务自身的问题其实也很明显。第一个是上手难度大，第二个问题就是部署包变多，以及多个小服务如何组装成一个大系统，还有微服务之间的依赖关系错综复杂，该如何管理。

这些都是微服务是逃避不开的问题。我在论坛上看到过一句话，开发觉得微服务是个好架构，但是运维不这么认为。我认为没有一个很好的技术体系的支撑，就不要轻易地采用服务。

如何缓解微服务架构带来的弊端

能力支撑

首先我们要提供一个能力的支撑。所谓能力的支撑就是要把基础组件全部提供给业务开发部门。

其次我们要提供完善的运维支撑平台和监控体系。

当平台研发团队对业务团队进行支撑的时候，他们在使用微服务架构的过程当中有任何问题，我们都能为他们提供一个良好的支撑。

自动化

一键发布单个微服务。在一个项目当中可能有二三十个微服务，我们要把每一个微服务都能够一键发布。

第二要是要一键发布整个系统。因为有时需要重启整个系统，这个时候就要能一键发布整个系统。

什么样的系统需要采用微服务

我认为第一规模要大，是指人员多，或是代码函数多。

第二个就是复杂度高，是指业务复杂，比如金融系统。

第三需要长期演进。如果是单体的，可以在演进过程中打上层层补丁。我们使用微服务把bug控制在一个小范围之内。

这三种情况可以考虑使用微服务架构。

采用微服务架构后，如何正确的姿势做技术管理

原来我们在进行沟通的时候，几乎都是以数据的形式。比如两个人在开发一个系统里面的两个模块，当我要调你的功能都是去看你的数据，一般情况下不会直接调用API，而现在不可以，因为我们的库和微服务都已经把它分离开了。所以现在的沟通方式产生了一个变化，当我们需要一个功能或数据，都是去调别人的API。

管理模式会产生变化。因为原来单体的时候，研发做项目技术管理有两种形态，第一种是老板盯着员工干活（气死型），第二种是老板拉着团队干活（累死型）。我们是希望可以形成一个自主执行的团队，老板给员工指明一条路，大家自发地去干。

大家的职责划分非常明确，我们是一个自组织性的团队。我们是微服务的主人，要对微服务负百分之一百的责任，形成一种责任感。

对风险的控制。我们不要做一个单体系统，单体系统会导致风险在整个系统的范围内流窜，只要把这个系统把它拆小，把它简单化了，就能够在某一些小的范围里面来控制这些风险。

知识的积累。我们原来是用共享库的形式，但弊端很明显，它的版本升级、前端页面、非功能需求都无法实现。我们现在可以以完整的微服务形式来进行知识的积累。

亚马逊创始人在2002年的时候就说，所有团队的模块都要以Service Interface的方式将数据和功能开放出来。不这么做的人会被炒鱿鱼。

我们采用的微服务架构技术

持续部署

我们在做的时候用了Jenkins的API来调用运维平台，然后运维平台里会发命令来调用docker的API。

环境迁移

在开发环境上，我们开发了一个程序包，开发人员做完测试以后，我们需要去往测试环境上迁移。

我们把开发环境上做出了一个镜像，然后把它推向docker registry，在测试环境里就可以把它拉下来，测试人员直接测。

在这个过程当中，最开始的时候是在开发环境上，开发人员测试完了以后就再也不会用到Jenkins，这个时候都是以镜像来进行迁移，后面到生产环境也是一样，这叫不可变的迁移。

API

微服务很多都提供了API，这就要牵涉到API的安全。微服务开发出来的API一般情况下会有两个用途，一个是给自己内部的其他业务模块来调用，一种是对外提供服务，给我们的合作伙伴调用。

微服务监控

Diamond主要用来是对数据库指标和主机指标来进行采集。为了后期维护和升级的方便，我们选择了Diamond。

第二个就是Flume。我们主要用它来对日志进行分析。

第三个是Metrics。主要是对JVM的指标进行检查。

最后一个就是Cadvisor。是google的容器监控工具。

我个人觉得如果我们选择这些小小的监控组件，灵活性会更高。

API的管理及测试

假如有二十个微服务，一个订单模块要被商品模块调用，那它要知道有哪些API以及API的参数是什么，参数的含义是什么。有两种做法，第一种就是写文档，但是这种做法出现的问题是代码和文档不一致。所以我们选择了swagger。第一不用写文档，第二它用别人的API的时候变得方便了，因为swagger可以自动生成一个API的页面，非常好用。API测试用的是rest-assured。

API调用

这是指微服务之间的API调用。我们选择的是Eureka、Ribbon、RestTemplate和DCTrace，DCTtrace是我们自主研发的调用链管理模块。

API安全

API对内部来说，比如写了20个微服务，那么门户或者移动端要来调动这些API，该怎么调用呢？我们写了一个叫门户后端的模块，它根据路由的规则把请求转发到路径指定的微服务的API。

微服务整合

我们在用户管理和权限管理的基础上加入了模块管理，用户看到的就是一个整体的系统。

总结

我觉得微服务架构是技术升级，但是如果我们的管理管理方法或者领导的管理、支持不跟上的话，微服务也是比较难做的。因为它的沟通方式、团队的组织形式或是对团队的要求都已经在产生变化，所以大家要做微服务架构首先要得到领导的支持。

谢谢大家！

相关推荐
B站高性能微服务架构
干货 | 微软首席研发经理缪瑾：从多元化的微服务支持看开放的Azure
干货 | 沪江学习系统技术经理黄凯：沪江任务调度系统微服务化介绍