如何支撑微服务架构落地

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

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

摘要

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

嘉宾演讲视频地址：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

• 干货 | 沪江学习系统技术经理黄凯：沪江任务调度系统微服务化介绍