微服务是一种软件架构风格，以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。在过去，我们更多的还只是听到微服务这个概念，但是现在，已经有很多微服务落地项目了，并且可以看到越来越多的企业在向微服务架构转型。
企业到底要不要转向微服务，又该怎么向微服务转型？关于这些问题，InfoQ 采访了 BoCloud 博云高级解决方案架构师赵安全，来看看企业在微服务转型中应该注意什么。
微服务面面观
不得不说，现在“微服务”在各大博客、技术订阅号和技术会议中出现的频度越来越高。然而，像其他新技术一样，对于微服务很多人都是“一解释就懂，一问就不知”。那么到底该如何理解微服务呢？
在赵安全看来，对于技术的理解主要看大家有什么样的需求。对于微服务而言，它可以解决企业的哪些需求呢？
首先是服务复用。企业内部会有很多应用，每个应用都会有一些通用的东西，比如常见的通知、授权等，还有些内部的特殊服务，如何把这些服务通用起来，就是服务复用；
其次是对分布式高可用、高弹性和高性能有需求；
还有一个方面跟 DevOps 理念相关，就是要支持快速迭代。如果应用架构不改，是无法在 DevOps 实践中实现快速迭代的。
很多人会问微服务和 SOA 的区别，其实从核心需求来讲，微服务架构和 SOA 区别并不是特别大。但微服务有个比较重要的点，就是可以独立部署，独立发展，这是跟 SOA 最主要的区别。服务可以独立部署就更容易快速迭代，这也是微服务要解决的一个问题。
微服务在满足我们诸多需求的同时，也带来了极大的挑战：
- 微服务把一个服务拆分成了很多个，维护的对象就变多了；
- 维护对象变多之后，如果一个任务出现问题，将很难定位出现问题的节点；
- 微服务化开发需要熟悉微服务开发框架、中间件，需要考虑失效、容错等策略，给开发也带来了新的挑战；
- 微服务如果拆分不好，会大量引入分布式事务，处理起来会比较麻烦；
- 对测试的挑战就更大了，微服务化之后，单一模块无法独立完成业务功能，而集成测试会在非常靠后的时候才能做，就要求需要大量引入 API 自动化测试等测试方法。
我适合向微服务转型吗
那么，眼看别人都在向微服务架构转型，企业自己要不要转向微服务呢？赵安全认为，是否要做微服务，主要考虑如下几个方面：
- 从需求角度考虑，有互联网化的弹性、快速迭代、高并发、高可用的需求。
- 企业业务复杂度高，需要长期演进。
- 企业有业务复用的需求，希望能减少重复造轮子，降低成本。
另外，从行业角度来说，目前一些大型的国企和金融机构都在向微服务转型，为什么是大中型的企业呢？因为他们本身的应用项目不是一次可以做完的，而是需要基于一个产品做长期的持续演进开发的过程，业务复用的需求也很迫切。如果是一个固化从来不升级的产品，就没有做微服务化的意义。
企业落地微服务的难点
对于决定要落地微服务的企业，赵安全列出了四个难点。
第一，首先要捋清需求，判断自己是否要做微服务。如果只是做了服务拆分而并没有复用的需求，或者没有高并发、弹性甚至是分布式的需求，做微服务的意义也不大。
第二，微服务设计上有难度。很多企业以为就是把服务简单拆一下就可以了，这明显是不靠谱的。微服务的拆分设计，一定是要花很多时间的。微服务产品前边的设计一定要做详细，把 API 等因素全都想清楚了再开始做。
第三，流程上也有一些变化。新需求来了怎么办？是在原来的微服务里重新修改，还是做一个新的微服务？这是需要从中间去考虑的，而不是像原来一样，有需求过来就开始改。
第四，在技术方面，其实掌握一套框架也需要时间。Spring Cloud 框架并不是特别简单，需要理解它的流程和方法，开发人员的开发习惯或方式可能也需要发生一些变化。
以上就是今天的内容，希望对你有所帮助。
