timethinker
2022-05-19 15:32:28 +08:00
给微服务一个定义吧，普遍认为的微服务就是把什么订单、用户等等系统拆分出来当作一个独立的项目来开发和部署，但是需要注意这个“拆分”只是逻辑上的。
比如我在开发的时候将所有的服务都放在一个项目里面，然后最终只打包出一个可执行文件来，分别在 ABC 机器上面进行部署，然后在 nginx 上面针对请求的 URL 路径转发到不同的机器上。我可以在 ABC 机器上面都分别配置不同数据库，毕竟这台机器只负责部分子集，只会操作部分的数据表，这样一来出现的一个问题就是 ABC 之间数据不互通了，比如订单需要查询用户信息，调用 UserService ，UserService 将不会查询到用户数据，因为这些数据存在于另一台机器和另一个数据库上，一种办法是 ABC 三台机器使用同一个数据库，这样可以解决数据互通的问题。注意自始至终我没有使用到 RPC 以及消息队列，我只是将同一个程序部署到了三台机器上，每一个机器负责部分的 URL 请求，你说这算不算是微服务呢？
如果你认为不算，我们可以改造一下，当某一个机器调用 XXXService.doSomething()的时候，实现不再是通过 JVM 进程内直接调用对象方法，而是通过构造 HTTP 请求另外一台专门负责这服务的机器来进行处理，这样一来，我们就可以将 ABC 三台机器又恢复到使用各自独立的数据库。如果我们拆分得足够好，三台机器应该至始至终只会生产和查询自己负责的那几张表。你说这算不算是一种微服务呢？
注意不管我如何部署，我们的开发结构仍然是一个单体的大项目，所有的代码在变更以后都需要重新打包然后部署到三台机器上面，但是如果我只修改了 A 机器负责的功能，我可以只更新 A 机器那一份，只要接口没有变动，其他两台机器仍然可以正常请求。
既然 ABC 都只负责部分功能，那为什么不在开发的时候就建立 3 个项目呢？这样岂不是更加清晰吗？的确可以这么做，但是我想说的是这样并不是必须的，或者说这不是重点，那么重点是什么？重点就是你如何确定这是 3 个项目而不是 4 个或者 5 个呢？是根据有 3 台机器我们就得有 3 个项目吗？所以重点就是如何找到进行拆分背后所隐含的那些逻辑，这些逻辑就是你的业务组织方式。
早前，我以为开发微服务就是把各种 Service 拆分出来当作一个独立的进程，使用独立的数据库，然后通过 RPC 进行相互调用，成功的把的注意力集中到了各种注册中心，网关，配置中心等等令人眼花缭乱的东西上面去了。在经历各种各样的填坑之后，回过头来再想一下，如果我只是作为一名开发，真的有必要去了解这些东西吗？我把大量的时间浪费在了去研究这些鬼东西上，反而把应该排在第一位的需求给丢到了一边。当服务网格和容器化出现以后，我对微服务这个词有了一些不一样的定义，说到底微服务终究不过是一种部署策略，它不是什么开发架构，它只是一系列指导如何正确开发服务的约定和理念，有了这些理念，我们就可以更容易的开发出适配部署运维的应用服务。微服务的终极目标，不是教我们如何用什么开发框架，用什么中间件，而是为了实现如何使资源利用得更加合理，更加有弹性，更加可伸缩。