关于微服务的一些思考

最近很多人问我一些微服务相关的问题，这让我对微服务有了一些思考。

首先， 微服务并不是银弹。

场景一：需求是这样的，做一个学雷锋活动的小活动页面，用户可以通过转发该页面成为火炬手，后台做统计并展示在页面上；

需求中没有复杂的功能和页面，这样的需求需要用微服务吗？我个人的做法是都不要前后端分离，Spring boot Thymeleaf就可以满足需求。

场景二：需求是这样的，为了响应上级号召，下级部门需要做一个数据上载平台，总共有7个大板块，56个小板块，主要功能是系统自动获取或用户主动录入信息，由系统将信息推送到上级平台，预计系统使用人数不超过10个，使用频率是以月为单位。

对于这样的一个需求，需要将信息录用于信息推送拆分为两个服务吗？需要使用到微服务吗？我个人的做法是使用Spring boot单体项目。

在引入微服务的时候必然会增加系统的复杂度，最简单的服务注册中心和调度中心得有吧，然后网关得有吧，光这些就别单体项目大了一圈，更别说其他的中间件集成了。

大道至简，简单的结构，简洁的代码，程序员的工作是让复杂的事情变简单，而不是让简单的事情变复杂。

再来说说这些年用微服务的体验吧。

接触的微服务项目中，有自研框架的，也有RuoYi、Jeecg这种开源的框架，像市面上其他的开源项目比如芋道源码这些也了解过。

我个人首推RuoYi框架，一方面知名的开源框架，了解过的上手基本都没有什么问题，其中代码很规范还有相应的文档，也有对应的生态，比如RuoYi-Plus等众多的二开项目；

关于Jeecg,我是用着很头疼的，因为很多底层的工具作者包装后都指向了他自己的代码仓库，改起来很费劲，基本没有可改性，这点对于想要二开的团队的话就有点坑了。其实Jeecg的生态还是很丰富的。

先写到这里，晚点再续更...