微服务架构解决了什么问题

引语

学习了沈剑老师的《微服务架构究竟解决了什么问题》课程，记录一下学习笔记。 现在基本上互联网公司招人就是问微服务，那么为什么要用微服务架构？它究竟解决了什么问题？有什么好处和缺点呢？

课程里有一句话很有感触就是不能大家都在用什么技术你就要用什么技术，应该是要了解它的优势和缺陷，对于合适的场景使用合适的技术架构。

传统互联网架构的问题

先看下典型的互联网架构。

方式一：从客户端到反向代理，再到高可用的web集群，web服务在直接访问db集群。 方式二：应用服务和dao，数据库都放在同一台服务器上

然后这样的结构是会产生一些问题，如下：

痛点一：代码到处拷贝

这种问题很多公司估计都存在，业务线A，B，C都会有用户服务，然后每个业务线有一些个性化的需求，可能A业务先写了一套用户服务的代码，这个时候业务线B也需要用户服务可能就是直接拷贝过来A的代码。

然后自己做一些修改。然后再来个业务线C可能也是如法炮制。这样用户服务就有了三份，而且代码还做了不一样的优化和修改。这样其实用户服务的代码就没有被复用起来，而且假设后面用户服务要统一起来做成一套，那每个业务线因为做了自己的个性化修改，其实重构也是很有难度的

痛点二：底层复杂性扩散

随着数据量的上升，底层数据库可能会分库分表，引入缓存等操作。如果每个业务线都自己弄一套，自己来改造升级，那么改造量蒋辉很大，底层数据库只要做些改动，那每个业务线都得做修改。

痛点三：公共库的耦合

公共的jar包就可以满足同一份代码，各处都可以使用，会减少代码的重复。不过会存在版本的问题，每个业务线的使用的版本是不一样的话，会出现问题。 这里需要公共库的代码升级的时候要做好兼容，防止版本不一致会出现兼容性的问题。

痛点四：sql质量无法保证

每个业务线写sql的水平不一致，初级工程师的sql写的可能就比较性能比较差，资深的工程师写的sql就比较高效。如果初级工程师写了一个低效的sql会导致数据库cpu飙升，导致其他查询都变慢。 此时如果很多业务线使用的是同一个数据库，会导致其他业务线的sql性能都受到影响。

痛点五：不易扩展，数据库耦合

各个业务线都使用了自己的个性化数据，用自己的业务表去join底层数据库的用户表，那么当用户表数据量很大的时候要垂直切分的时候，因为各个业务线的sql都和用户表耦合了。想切分的时候，每个业务线都得跟着一起修改，扩展性很差。

以上就是典型业务架构会带来的一些问题，如果引入一个中间层服务层，专门负责用户服务的话，就会带来以下的优点（和上面的痛点相对应）。

好处一：复用性，消除代码拷贝

比如拿上面的用户服务来说，所有的业务线都使用同一个用户服务，代码都是同一份只需要根据对应的版本做好升级和版本控制就好了。对于实现用户服务的开发者，则要做好版本之间的兼容性，升级的时候要提前通知好，防止有些接口下掉带来的线上问题。

好处二：专注性，防止复杂性扩散

对于用户服务来说如果做成一个单独的服务的话，不管是分表还是增加了缓存或者是底层实现的修改只要保证对外的接口不变，或者新功能增加新的接口就行了。对于调用方来说只要调用接口就好，根本不用关心，底层数据储存的变更和优化等问题。

好处三：解耦合，解除公共库的耦合

代码复用性的问题已经解决了，主要是线上实时的接口保证好兼容性。

好处四：高质量，sql稳定性有保障

服务因为是同一个只要这个服务写sql的人是比较资深的人，或者写完有sql功底比较扎实的人去review就能很大程度上保证sql的质量和稳定性。

好处五：易扩展，消除数据库解耦合

所有业务线都没法直接join主库了，需要自己在业务上去做处理，这样底层数据库的垂直拆分，分库分表对上层的业务系统就没有耦合了。

好处六：高效率，调用方研发效率提升

业务开发更加专注，只关心自己的开发部分。底层接口的实现，缓存，数据库的效率都不用关心。

服务化的问题：

当然微服务引入的同时也会带来一系列的问题，主要是系统的复杂性和对程序员的开发，运维的维护复杂度会提高。细化问题就是下面这些，服务化的问题：

1.系统复杂性上升 2.层次变得复杂 3.运维部署更加复杂 4.监控变得更复杂 5.定位排查问题更麻烦

总结

服务化并不是简单的引入一个RPC框架，需要添加一系列的基础设施配合才能完成微服务的架构。微服务会让开发的边界很清晰，每个开发者只要负责好自己管控的部分即可，开发非常高效。

但使用微服务也会有一些问题，经常会有使用的服务的jar包版本更新，接口更新或改造，调用方也会跟着要改。因为这个实现不在调用方自己控制，受限于实现方，不过这个我觉得主要是要约定好更新的节奏，接口更新的时候提前通知好，或者修改接口不是一次性替换，而是新加一个接口，老接口先留着，待调用方改造完，再把老接口下掉。

总的来说微服务在业务量比较大的公司可能会叫好用，体量比较小的公司用的话会引入更高的复杂度，人力本来就比较少的情况下会增加开发的难度和时间，根据自己公司的发展情况和阶段来使用合适的架构才是比较正确的思路。

作者：我想问问天 来源：https://blog.csdn.net/sc9018181134/article/details/110780272