写点什么

企业落地微服务的避坑指南

  • 2019-08-16
  • 本文字数:3757 字

    阅读完需:约 12 分钟

企业落地微服务的避坑指南


微服务是一种软件架构风格,以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。在过去,我们更多的还只是听到大家都在谈论微服务这个概念,但是现在,已经有很多微服务落地项目了,并且可以看到越来越多的企业在向微服务架构转型。企业到底要不要转向微服务,又该怎么向微服务转型?关于这些问题,我们采访了 BoCloud 博云高级解决方案架构师赵安全,来看看企业在微服务转型中应该注意什么。

微服务面面观

不得不说,现在“微服务”在各大博客、技术订阅号和技术会议中出现的频度越来越高。然而,像其他新技术一样,对于微服务很多人都是“一解释就懂,一问就不知”。那么我们到底应该如何理解微服务呢?


在赵安全看来,对于技术的理解主要看大家有什么样的需求。对于微服务而言,它可以解决企业的哪些需求呢?


  • 首先是服务复用。企业内部会有很多应用,每个应用都会有一些通用的东西,比如常见的通知、授权等,还有些内部的特殊服务,如何把这些服务通用起来,就是服务复用;

  • 其次是对分布式高可用、高弹性和高性能有需求;

  • 还有一个方面跟 DevOps 理念相关,就是要支持快速迭代。如果应用架构不改,是无法在 DevOps 实践中实现快速迭代的。


很多人会问微服务和 SOA 的区别,其实从核心需求来讲,微服务架构和 SOA 区别并不是特别大。但微服务有个比较重要的点,就是可以独立部署,独立发展,这是跟 SOA 最主要的区别。服务可以独立部署就更容易快速迭代,这也是微服务要解决的一个问题。


微服务在满足我们诸多需求的同时,也带来了极大的挑战:


  • 微服务把一个服务拆分成了很多个,维护的对象就变多了;

  • 维护对象变多之后,如果一个任务出现问题,将很难定位出现问题的节点;

  • 微服务化开发需要熟悉微服务开发框架、中间件,需要考虑失效、容错等策略,给开发也带来了新的挑战;

  • 微服务如果拆分不好,会大量引入分布式事务,处理起来会比较麻烦;

  • 对测试的挑战就更大了,微服务化之后,单一模块无法独立完成业务功能,而集成测试会在非常靠后的时候才能做,就要求需要大量引入 API 自动化测试等测试方法。

我适合向微服务转型吗

眼看别人都在向微服务架构转型,那企业自己要不要转向微服务呢?


赵安全认为,是否要做微服务,主要考虑如下几个方面:


  • 从需求角度考虑,有互联网化的弹性、快速迭代、高并发、高可用的需求。

  • 企业业务复杂度高,需要长期演进。

  • 企业有业务复用的需求,希望能减少重复造轮子,降低成本。


从行业角度来说,目前来看,一些大型的国企和金融机构都在向微服务转型,为什么是大中型的企业呢?因为他们本身的应用项目不是一次可以做完的,而是需要基于一个产品做长期的持续演进开发的过程,业务复用的需求也很迫切。如果是一个固化从来不升级的产品,就没有做微服务化的意义。

企业落地微服务的难点

首先,一个很大的难点是要捋清需求,判断自己是否要做微服务。现在一个普遍的现象是,大家没想清楚为什么要做微服务就开始做了。如果只是做了服务拆分而并没有复用的需求,或者没有高并发、弹性甚至是分布式的需求,做微服务的意义也不大。


其次,微服务设计上有难度。大家不知道怎么设计,以为就是把服务简单拆一下就可以了,这明显是不靠谱的。微服务的拆分设计,一定是要花很多时间的。微服务产品前边的设计工一定要做详细,把 API 等因素全都想清楚了再开始做。


第三,流程上也有一些变化。新需求来了怎么办?是在原来的微服务里重新修改,还是做一个新的微服务?这是需要从中间去考虑的,而不是像原来一样,有需求过来就开始改。


第四,在技术方面,其实掌握一套框架还是需要时间的。Spring Cloud 框架并不是特别简单,需要理解它的流程和方法,开发人员的开发习惯或方式可能也需要发生一些变化。

企业怎样做微服务?

企业到底应该如何来做微服务呢?赵安全介绍到,整体来讲,做微服务主要要考虑到微服务的拆分、架构选型和架构演进。

微服务拆分原则

微服务拆分中,核心的需求在于拆开的微服务之间的联系越少越好,虽然我们强调复用,但是联系越少越好,数据交互也是越少越好。因为微服务之间的数据一致性非常难处理,如果一致性方面的问题很少,整体做起来就比较简单了。

微服务架构选型

微服务架构的选型也是一个让大家比较纠结的事情。赵安全说,从过去的经验来看,选择开源技术时,社区的活跃度是非常重要的参考。但博云在做选型的时候,有一些组件并没有按照所谓的社区活跃度来选,就是因为还有第二个选型的原则:一定要满足需求,这是要重点考虑的。第三点原则是掌控能力。假设一个框架是用 C 语言写的,整个团队没有懂 C 语言的人,这样肯定不行。因此总结下来就是,微服务架构选型需要考虑:社区活跃度、需求满足度、掌控能力,这三方面。


拿 BoCloud 博云的微服务平台 BeyondMS 来说,BeyondMS 的框架有两套:



基于 Spring Cloud 的框架,博云在 Spring Cloud 的基础上做了一些变化:


  1. 因为 Zuul 的性能问题,BeyondMS 的 API 网关从 Zuul 改成了更高性能的 Kong

  2. 因为 Spring Cloud 原生的配置中心能力相对弱一些,服务配置中心使用了携程开发的 Apollo。



  • 第二套是博云根据客户需求自研的基于 gRPC 的微服务框架,可以支持多语言,未来也会支持 Istio。


基于 gRPC 的框架主要用到 ZooKeeper,也是用了 Kong 做 API 网关,跟 gRPC 做集成。因为 gRPC 本身是一个 RPC 框架,没有一套完整的服务治理,所以博云就自研了一套针对多语言微服务框架。目前 BeyondMS 微服务平台已经在多个金融机构落地应用。


微服务架构演进方式

说到微服务架构的演进,赵安全比较认同微服务是长出来的,而不是设计出来的。完全架空地去做一套新系统当然可以做好微服务架构,但是很多时候我们没有这种条件,都是在一个已有的系统里去做。这样我们的架构演进方式就是:有了新需求,做一个独立的微服务,慢慢做成服务化互相调用,然后把数据切分过来。但数据切分也不是一次就做完了,而是数据先在新老系统里都有,两边保持一致,慢慢地把数据迁移到新系统里去。最后的结果可能是原来的老系统还保留有一些东西,但是在它周边的很多新需求,全都是通过一个个独立微服务来做出来的,这就是微服务长出来的方式。


在项目的落地中,这种架构演进方式还是有很多风险的,也经常有客户采用完全中心开发的方式做微服务,比较简单纯粹,但需要多花很多成本。

微服务是需要大平台支撑的

微服务革新了软件的生产过程,包括开发、测试和部署各个阶段。但服务的切分并不是要遵守单一原则,因为未来的服务不可能完全垂直切分。从另外一个角度看,微服务的过程其实也是工业化的工程,每个微服务都是生产线上的一个零件,但要注意,零件的组装和拼接难度更大,所以在谈论微服务时一定要注意,它是需要一个大平台支撑的。


BoCloud 博云也有自己的企业级 PaaS 整体解决方案,整个 PaaS 平台底层是容器平台,它是 PaaS 中的一个基础设施;再上一层有应用的开发管理,应用的部署上线,以及应用的运行管理和开发管理。


微服务的开发框架就跟开发管理相关。此外博云还提供微服务咨询,这属于解决方案的一部分,包括了微服务拆分设计的咨询,以及微服务框架选型和微服务的开发指导。这两者属于开发过程管理。


对于微服务的发布上线和微服务运行的管理,博云提供了服务治理。监控和服务治理,是云平台管理的一个比较重要的方面。微服务上线是容器平台的事情,微服务运行管理就涉及到服务治理。


企业应该如何提升团队的微服务落地能力?

通过对自身服务案例的总结,赵安全也对企业提升微服务落地的能力给出了自己的建议。整体来讲,要做微服务,最重要的是整个团队要达成共识。现在开发团队经常会听到两种声音,第一种声音希望借助新技术,发展新东西,另外一种声音是希望按部就班什么都不要变。第一种声音和微服务是比较匹配的,第二种声音对微服务是一种阻力。


所以首先大家还是要达成共识。很多时候微服务架构的改造都是试点项目,这就需要有愿意尝试新东西的人来做这样的事情。从企业落地来讲,如果第一个项目做失败了,后面很长一段时间内很多就没有机会了。


第二点是团队要有心理准备,提前做知识储备。因为微服务对开发、测试人员都带来了挑战,大家如果都没有储备的话,可能就需要多花很多时间。

总结

分布式计算和云计算给 IT 基础设施带来了巨大的变革,引领着这一轮的数字化转型。面对众多的事务,弹性扩展的需求,微服务架构已经在云计算时代 C 位出道,满足我们的诸多需求。


微服务之路的想法是好的,但是在追赶微服务浪潮之前企业和团队应该负责任地进行考虑,做好权衡取舍,切忌盲目跟风。微服务架构首先要关注的不是 RPC、Service Discovery 这些概念,也不是 Eureka、Zipkin 这些技术框架,而是服务的边界、职责划分,划分错误就会陷入大量的服务间的相互调用和分布式事务中,这种情况微服务带来的不是便利而是麻烦。


所以,微服务转型,你准备好了吗?

作者简介:

赵安全,博云高级解决方案架构师,在 IT 架构和云计算等领域有超过 12 年的丰富经验,认证 DevOps Master。先后负责过民生银行、江苏银行、佰仟金融、中石油等容器云 /Devops 项目的技术方案、架构设计、落地咨询等工作。对云计算、DevOps、分布式架构有深入的研究和理解。


2019-08-16 13:578698

评论 2 条评论

发布
用户头像
文中还是没有提及到如何避坑,有哪些具体的坑?泛泛而谈了
2020-12-12 22:26
回复
这都是大场面,不是一线干货
2020-12-13 11:00
回复
没有更多了
发现更多内容

这一篇让你彻底搞懂微信生态里的二维码

产品海豚湾

产品经理 产品设计 二维码 微信扫码 SaaS 产品

MAXHUB+腾讯会议:为未来办公造一部动力引擎

脑极体

企业金融App评测系列——微众银行以App构筑企业金融服务新生态,成为企业的随身数字银行

易观分析

企业 金融 银行

天猫联合瓴羊、贝恩,打造“产品致胜”的DTC发展模式

瓴羊企业智能服务

Java高手速成│编写你第一个数据库程序

TiAmo

JDBC 数据库· 12月月更

Docker 中的挂载卷

HoneyMoose

Mysql到TiDB迁移,双写数据库兜底方案

京东科技开发者

数据库 开源 开发 迁移 双写数据库

「实操」结合图数据库、图算法、机器学习、GNN 实现一个推荐系统

NebulaGraph

推荐系统 图数据库 图算法 GNN

丧心病狂,竟有Thread.sleep(0)这种神仙写法?

JAVA旭阳

Java JVM

华为云数据库GaussDB(for MySQL)全方位守护企业云上数据安全

爱科技的水月

如何写一个深度学习编译器

MegEngineBot

深度学习 开源 编译器 MegEngine MegCC

Code Review到底在关注些什么?

孟君的编程札记

Java CodeReview

如何在 15 分钟内度量 DORA 指标?

思码逸研发效能

研发效能

云上数字化时代,华为云桌面助力政企办公升级

IT科技苏辞

直呼内行,华为云桌面就是这么专业

IT科技苏辞

企业数据上云,华为云数据库 GaussDB(for MySQL)轻松解决

科技之光

【web 开发基础】PHP数组元素的添加和删除操作 (49)

迷彩

数组 数组操作 PHP基础 先进先出 后进先出

物联网 IOT 设备如何脱离信息孤岛?

eng八戒

物联网 IoT 网络 网络配置 涂鸦智能

基于聚类算法的话术挖掘技术及在营销服场景的落地应用

中关村科金

人工智能 大数据 算法 对话机器人 技术实践

架构实战营第10期模块3作业

Geek_4db2d5

内卷时代,华为云引领移动办公新潮流

清欢科技

HTTP实体首部字段

穿过生命散发芬芳

HTTP 12月月更

架构实战营模块三作业

张贺

「Go框架」http请求处理流程: gin、beego等web框架是如何处理http请求的?

Go学堂

golang 开源 程序员 个人成长 12月月更

无魅友,不魅族!魅族大力推广魅友文化,用行动阐述何为用户共创

极客天地

使用 QuTrunk+Amazon ParallelCluster3 进行并行计算

亚马逊云科技 (Amazon Web Services)

亚马逊云科技 Hero 专栏

守护企业数据安全,华为云数据库 GaussDB(for MySQL)有绝招

科技之光

华为云数据库助力微鲤科技智能升级

爱科技的水月

Git使用教程之本地仓库的基本操作

芯动大师

git git 学习 Git命令行

Content-Length使用不规范导致Socket Hang Up问题

Kevin Wu

TCP HTTP HttpClient content-length

2022-12-27:etcd是无界面的,不好看,joinsunsoft/etcdv3-browser是etcd的web可视化工具之一。请问在k3s中部署,yaml如何写?

福大大架构师每日一题

云原生 k8s etcd k3s 福大大

企业落地微服务的避坑指南_架构_赵安全_InfoQ精选文章