公司要转型微服务，真的有必要么？

今天参加了DevOps的国际峰会，一整天听了两个专题，分别是和微服务相关的，以及和kubernetes相关的，现将听后的一些心得记录下来，分享给大家。

文/谦益

这篇主要是给大家分享微服务相关的。

现在，在互联网圈子里，不知道何时微服务这个概念已经深入到了我们圈内的各个角落，似乎如果不赶上这个潮流，公司的产品就将被淘汰了。

这个专场开场时，老师给我们说了个他的一段经历。

一天他邻居问他：“你的微服务课程我可以去听么？” 老师很是惊讶，说：“你做微商的怎么这么好学呀，你知道啥是微服务么？” 邻居说：“微服务不是为微商服务的么？”

当然这略带有点喜剧性了，不过对于微服务，真的是和我们理解的那样么？我在听这场分享之前我一直认为，微服务不就是把业务按照功能模块切割，让他独立出来么？

听完这场分享，对微服务的定义，有了全新的认识。

01 微服务不是简单的模块切割

目前业内对微服务存在的误解有很多，这里ThoughtWorks的架构师和坚老师给我们列出来几点：

看完这些，我就有点蒙圈了，那到底怎样的才算微服务呢？下面是老师对微服务的一个概括：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等

同时和坚老师给我们分享了微服务具有以下几点特点：

我这里的理解是微服务其实是围绕业务能力组织进行划分的一整套服务集群，但是该怎么划分呢？他的粒度是什么呢？

假设有一天你的系统已经进行了“微服务”改造，由于你的业务发展，新的需求如潮水般涌来，渐渐的发现某些“微服务”开始慢慢的膨胀起来。

发现膨胀的“微服务”有一部分业务又需要拆分了，而且这个服务内部还高度耦合，这不就又变成了，拆分之前的服务了么？

你拆分成的不是微服务，而是一个小的单体。

关于怎么拆分微服务，和坚老师给我推荐了一个叫DDD服务设计的思想：

要求我们从业务视角去分离复杂度，最终目标都是为最求高响应力。

让业务架构和系统架构形成绑定关系，从而当我们去响应业务变化调整业务架构时，系统架构的改变是随之而发的。

虽然短短的两句话，但是要理解做好，真不是那么容易，还待深入学习。

目前微服务只存在一个概念性的阶段，要想将我们现有的服务切分成微服务，按照什么标准进行切分，不同的行业，不同的业务场景，将是不同的，这是一个难题？

当我们辛辛苦苦的把业务切成了一个一个小的服务在跑时，如果哪天业务发展，发现这两个服务还是和在一起跑比较好，这时，你将面临的不是单单的把两个代码合在一起这么简单。

代码上的冲突，修改上下游的依赖，部署架构都将是一个挑战。

微服务的合并，比拆分更难。

当我们的项目被拆分成了微服务在线上跑了，我们的开发看到的将不再是一整个业务的代码，而是一个一个小的模块服务。

我们的开发将面临：我们得把整体的所有服务了解个遍，或者相关的服务模块了解完。

如果不能了解完，将会出现：在版本迭代时，我们修改的代码，能保证这个服务上没问题，不能保证上线后对其他的业务不会有影响。

对于这个问题，微软的MVP陈锋逸老师提出了一个建议，借助一些代码即架构的工具来弥补这块。

微服务落地，我们还将面临，我们的服务散落在各个地方，运维的同事将怎么进行监控，怎么知道此时此刻哪个服务挂了，哪个服务超载了，超载时我们怎么进行扩容，这都是我们要解决的问题。

还有，如果我们辛辛苦苦做成了微服务，在版本发布时，怎么保证线上所有容器的版本一直性，也是要解决的问题。

这一系列的问题就涉及到可持续性交付这块了，从开发提交代码，到测试，到构建，再到测试用例的覆盖，最后到生产这一连贯的工作，怎么让他们自动化？如果做不到自动化，那投入的成本将可能是传统的架构的N倍。

我不是一个架构师，只是一个小小的开发者，所有行文都是按照一个开发者的角度结合今天老师讲的所写，所以可能有诸多不恰当的措词，欢迎指正。