转载

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

微服务是一种软件架构风格，以专注于单一责任与功能的小型功能区块 (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 的框架，博云在 Spring Cloud 的基础上做了一些变化：

因为 Zuul 的性能问题，BeyondMS 的 API 网关从 Zuul 改成了更高性能的 Kong 。
因为 Spring Cloud 原生的配置中心能力相对弱一些，服务配置中心使用了携程开发的 Apollo。

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

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

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

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

微服务架构演进方式

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

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

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

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

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

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

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

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

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

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

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

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

总结

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

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

所以，微服务转型，你准备好了吗？