Go微服务实战2：了解微服务

上一篇文章深入探索了为什么选择go语言来开发后台，我们书接上文，来聊一聊后台开发的架构，本文的目的很简单：让刚入门后台开发的小伙伴了解后台开发架构变化。

目前后台开发中最流行的是微服务模式，其背后的思想有点类似于软件设计中“单一职责”的原则：只做一件事，并且把它做到极致。

我们回顾一下后台架构的演进史，从历史中寻找推动架构变化的原因。

单体架构

要想搞明白微服务，先得了解单体架构，一般小公司在项目规模还不是很大的时候，为了快速上线新功能，往往会采用这种架构，这种架构就跟它的名字一样简单易懂。

设想现在要做一个电商项目，核心功能点有创建订单，验证库存，物流配送等，在服务端具体实现时就会对应有产生不同的功能模块：用户模块，订单模块，物流配送模块。

在单体架构模式下，这些模块会做为整体部署到一个进程中，其结构如下图：

一个nginx反向代理服务器做负载均衡，一个数据库，再加上一个打包运行在容器中的业务进程，这基本上就是单体架构的全部了。

注意图中所有的功能模块都是在同一个容器中，这是单体服务的最大特点。

这种方式有什么优点呢？最大的优点就是简单，特别适合业务功能较少较简单的场景，一般新项目的前期阶段，功能少，需求不是很复杂，为了快速上线快速迭代，采用这种方式是个很不错的选择。

但单体的缺点也同样明显，这玩意就像赤壁之战时曹孟德铁索连成的大战船，看上去威风凛凛稳如泰山，但是一旦一个点开了花，一切瞬间完玩。想想看，某个模块的开发埋了个雷，会在特定的条件下触发，测试的时候没发现，上线后被触发暴雷了，然后整个进程都重启，过不了多久又触发暴雷又重启... 所有业务都无法服务。

在经过无数项目的历练之后，越来越多的人感受到了单体模式的不足，总结起来主要有下面几点：

• 代码库庞大：所有的业务代码都在一个工程中，随着产品需求和功能的不断堆加，代码会变得越来越多并且难以维护；
• 模块边界模糊：不同的模块可能用一个文件夹区分，实际的依赖关系很难理清；
• 构建部署问题：每次修复一个问题，整个应用都需要重新打包部署。试想一下，因为用户模块的一个小bug，就要重新打包部署整个应用，导致订单等其他模块在一段时间内也不可用，这对用户体验及其不友好；
• 阻碍技术创新：在单体应用下，整个团队只能使用相同的技术栈，要么大家都用Java，要么大家都用C++，如果你想尝鲜用用go，对不起，其余人可能没那么多时间陪你玩。

总结起来一句话：项目规模小的时候，单体足够应付，但是当规模上来以后，单体架构将无法满足需求。

微服务架构

说完了单体，再来说说微服务。微服务架构的哲学其实可以理解为设计模式中的单一职责原则：只做一件事并将它做到极致，它最早是在2014年由Martin Fowler和James Lewis共同提出，Martin Fowler是软件设计领域的大师级人物，他的几本耳熟能详的著作相信有不少小伙伴都听过：《重构》、《UML精粹》、《企业应用架构模式》。

微服务强调以若干组独立部署的服务来构建系统，注意这里的关键词：独立部署。仍以上面的电商系统为例，在微服务架构模式下，可以拆分出用户服务，订单服务，物流服务，这些服务在部署时不是做为一个整体部署到一个进程中，而是单独部署，化整为零，你打你的，我打我的，这就解决了前面提到的单体架构的一些痛点问题：

• 因为是单独部署的，所以某个服务出了问题，只需要修复问题以后重新部署服务（某些情况下有可能依赖该服务的其他服务也需要重新部署）即可，其他服务依然可以正常对外提供服务。
• 模块边界清晰：每个微服务就是一个独立的功能模块，有依赖关系的微服务之间通过RPC的方式交互。
• 技术栈可以异构：微服务模式下，每个服务的代码可以是独立的工程，你的服务用Java，我的服务用python，根据具体情况自有发挥。

微服务架构虽然解决了单体架构的大部分问题，但这并不等于说它没有缺点：

• 现在的微服务大多是通过RPC的方式调用，会损失一定的性能，而单体模式不会存在这个问题。
• 微服务模式下，很多服务都是使用各自不同的数据库，在某些情况下解决数据一致性问题会变得非常复杂。
• 当服务间有依赖时，问题可能会变的复杂，某个服务变更，可能还要周知依赖它的其他服务。
• 对于规模庞大的系统，微服务的划分并不简单，需要业务专家根据DDD妥善的分解业务。

关于服务发现

当使用微服务后，一个避不开的问题就是服务发现：那么多独立部署的服务怎么知道对方的存在呢？这就引入了微服务架构中一个重要话题：服务发现。

如果不考虑实现细节，服务发现的思想其实并不复杂：

• 有一个注册中心，所有的服务都注册到这里来，类似于咱们上户口，这样注册中心是知道每个服务的详细信息的（比如它的IP和端口）
• 服务随时有可能会挂掉，这时候就得把它注销掉，类似于销户，你总不能找一个已故的人办事吧，那岂非成了鬼差。
• 注册中心通过发送心跳包的方式周期性的检查一个服务是否还健在。
• 客户想找服务办事的时候，先通过注册中心找到服务，然后通过RPC的方式调用。

上面描述的这个流程可以用一张图来表示：

有好事的同学可能要问了：那注册中心挂了咋办？没错，注册中心是大脑，脑死亡了当然不行，所以注册中心在部署的时候肯定是要部署多台机器做到高可用。

用单体还是微服务

撇开具体的业务谈这个问题，有点耍流氓的意思，不能一棒子就把单体服务给打死，实际选型的时候还是取决于业务。

如果是初创公司，啥都没有，后台开发就一两个人，因为前期的业务可能不会特别复杂，量级也不会特别大，为了快速迭代可以选择单体的方式。

如果你发现业务成长很快，数据显示请求量级呈不断上升的趋势，这时候就需要尽早考虑拆分业务，切换到微服务模式，就像之前所说的，当业务规模大起来以后，单体的雷可能随时会爆。

如果条件允许，最好的建议还是一步到位，除非你认为短期内你的业务不会有太快成长。毕竟从单体切换到微服务是一个架构级的调整，可以说是伤筋动骨，如果真的等业务规模变大以后才调整会非常的麻烦，相关团队估计又得手忙脚乱熬几个通宵。

 总结

又到了小结时间了，本文旨在让刚入门后台开发的小伙伴们了解后台开发的架构，以期在技术选型时做到心中有数。

• 单体架构所有业务做为整体部署在一个进程之中，优点是部署简单，不需要RPC，性能高，主要缺点是一个模块的bug可能影响到所有业务，适合简单，小规模的业务。
• 微服务架构将业务拆分成独立部署的一组服务，避免了单体架构中一个业务bug影响所有业务的问题，但是引入了更多复杂问题（比如服务发现，分布式问题等），好在现在的微服务框架已经帮我们解决了这些问题，开发者可以拿来就用。

如果阅读完本文后您觉得有所收获，可以动动手指加个关注哦，一起学习，一起进步！