资讯 > 博云志

实践出真知:博云微服务经验之避坑指南
2018/8/20 14:09:24

目前每个企业都想做微服务,但如何做好微服务?微服务改造过程中有哪些必须重视的问题?博云通过自己的实践,总结了一些经验之谈。日前InfoQ对博云高级解决方案架构师赵安全就此话题进行了专访,以兹各位对微服务感兴趣的朋友们。

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

微服务面面观

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

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

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

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

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

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

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



我适合向微服务转型吗

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

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



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

企业落地微服务的难点

BoCloud博云作为企业级云计算解决方案提供商,帮助很多企业完成了微服务架构转型,从这些案例中赵安全总结出了微服务落地的几个难点。

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

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

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

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

企业怎样做微服务?

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

微服务拆分原则

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

微服务架构选型

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

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



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


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

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



基于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、分布式架构有深入的研究和理解。

版权所有:苏州博纳讯动软件有限公司     苏ICP备13004761号      声明:本站使用字体为北大方正授权许可正版字体