如何支撑微服务架构落地

编辑IT大咖说

阅读字数: 2265 用时: 7分钟

视频内容

摘要

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

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

什么是微服务架构?

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

微服务架构带来的好处

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

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

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

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

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

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

能力支撑

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

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

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

自动化

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

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

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

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

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

第三需要长期演进。如果是单体的,可以在演进过程中打上层层补丁。我们使用微服务把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。

微服务整合

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

总结

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

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2017-06-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

必读推荐:深入解读Oracle 18c对于DBA的影响及应对措施

? Joel Perez Oracle ACE Director,云和恩墨高级云技术专家 "DBA 将要失业了吗? 当引入自治数据库之后,就永远不需要...

4199
来自专栏hadoop学习笔记

DKHadoop大数据平台架构详解

大数据的时代已经来了,信息的爆炸式增长使得越来越多的行业面临这大量数据需要存储和分析的挑战。Hadoop作为一个开源的分布式并行处理平台,以其高拓展、高效率、高...

2350
来自专栏技术杂文

微服务:真正的架构模式

微服务的相关知识和它的神秘令我着迷。概念上的微服务就像是现代最有趣的流行架构之一。它足够功能强大,有着广泛的使用方法;也足够模糊,难以统一而论。

2483
来自专栏腾讯大数据的专栏

腾讯社交LBS服务技术要点

“如何在激烈的移动社交市场竞争中脱颖而出?”这是当前移动社交应用领域众多开发者们所面临的现实问题。在产品功能特性同质化越来越严重的形势下,动用最小的研发资源实现...

40110
来自专栏云计算

为您的组织选择正确的企业云解决方案

目前,云计算已被广泛使用,并且成为多数企业为之努力的目标。然而,入云所带来的现实问题也令人担忧。耗时费力的部署,安全风险,噩梦般的应用程序迁移场景以及不成熟的私...

2176
来自专栏子勰随笔

SDK那些事(总纲)

30710
来自专栏顶级程序员

程序员必须遵守的8大准则

再确认测试代码前,先找别人帮你检查下是否无误。在别人做之前尽量检查出bug并且将其处理好。代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代...

1134
来自专栏zzzz

hadoop大数据平台架构之DKhadoop详解

大数据的时代已经来了,信息的爆炸式增长使得越来越多的行业面临这大量数据需要存储和分析的挑战。Hadoop作为一个开源的分布式并行处理平台,以其高拓展、高效率、高...

1473
来自专栏IT大咖说

经历了研发困局、运维之痛,同程微服务从1到1w的旅程

内容来源:2017 年 9 月 9 日,前同程艺龙架构师谢康在“ArchData技术大会上海站”进行《同程微服务从1到1w的旅程》演讲分享。IT 大咖说(微信i...

1513
来自专栏腾讯大讲堂的专栏

解读腾讯社交LBS服务技术要点

“如何在激烈的移动社交市场竞争中脱颖而出?”这是当前移动社交应用领域众多开发者们所面临的现实问题。在产品功能特性同质化越来越严重的形势下,动用最小的研发资源实现...

2799

扫码关注云+社区