泉州网站建设推广,如何查网站是哪个公司做的,在哪个网站可以做车年检,开发app商城软件的公司文章目录 一、引出问题二、微服务2-1、微服务的技术2-2、微服务的目的 三、微服务的拆分四、不连表查询五、微服务的好处六、微服务的坏处七、应付当下 这篇文章原本叫《如何做到不连表查询》#xff0c;因为我对这个事一直耿耿于怀。在上家公司我经常被连表折磨#xff08;连… 文章目录 一、引出问题二、微服务2-1、微服务的技术2-2、微服务的目的 三、微服务的拆分四、不连表查询五、微服务的好处六、微服务的坏处七、应付当下 这篇文章原本叫《如何做到不连表查询》因为我对这个事一直耿耿于怀。在上家公司我经常被连表折磨连的多性能差最多的有二三十张。20年看阿里Java开发手册里面提到表连接不要超过三张我一直把这个当作笑话。直到入职这家新公司现在有四个多月了我没连一张表。 年初的时候看完了《凤凰架构》上个月看完了《微服务架构设计模式》加上这段时间的思考对微服务有了新的理解。 一、引出问题 举一个例子在上家公司有一个列表叫线索列表列表展示的字段有60多个离谱的的是这里面很多字段都要筛选。下面的每一个字段都要去关联一张或多张表才可以做到筛选
是否关注公众号是否添加企微用户标签最后一次call时间意向分用户触达次数重点客户标签…
在离职不久前还接到了一个离谱的需求要求记录用户的每次访问标记并且可以支持随意标记搜索比如用户访问了A、B、C、D 那么搜索其中任意一个就都可以搜索出来这个用户。
这些表里面有很多是百万、千万级别的。之所以系统还能运行全靠硬件。 不可否认经过一轮轮的折磨我的SQL功底要强了不少。 二、微服务 2-1、微服务的技术 我翻看我之前写的博客找到我最开始学微服务是在20年2月发布了一篇名为《SpringCloud项目整合【eurekaribbonzuulhystrixhystrix dashboard】》的博客。
其实就如这篇博客的名字一样最开始的微服务是Cloud它的代表是很多对应的组件我把这一套称之为微服务1.0。对于微服务1.0我并没有实战经验因为在我学完它不久之后我发现了微服务1.1也就是SpringCloud Alibaba。
为什么说SpringCloud Alibaba是1.1因为本质上它和微服务1.0很相似每一个组件在Cloud Alibaba里面都有一个与之对应的组件。21年4月我写一篇SpringCloud Alibaba整合的博客完整的SpringCloud Alibaba我是没有用过但用过一些它的组件比如现在公司的服务注册与发现用的是Nacos。
21年9月我入职了一家新公司这家公司用的是Kubernetes这是微服务2.0。在23年3月我写了一篇谈谈我理解的SpringCloud和Kubernetes的区别 Kubernetes相较于Cloud那一套有了很大的改进Cloud的一切都是嵌入到代码里面而Kubernetes意在剥离这些东西在使用Kubernetes的时候我们的微服务本质上就是一个SpringBoot的单体项目一样当然这个很大一部分原因是我们没有解决微服务里面所有的问题比如服务降级限流这些。 最近我又在书里面看到了未来的方向服务网格和无服务器。从单体到微服务的演变过程中带了很多的问题如注册与发现、负载、全局配置、分布式事务、服务的熔断降级、服务之间的通信等。
在Cloud里面每一个问题都有对应着一个技术组件在Kubernetes 里也有对应的组件但Kubernetes里面的组件相较于Cloud的来说它藏的深一点了比如服务的注册发现、服务的负载上了Kubernetes就自动完成了。
其实上面的这些问题和业务本身没多大关系我所理解的服务网格就是进一步弱化这些组件让这些问题的解决变成一个通用的方案以后只需要把我们写的服务一个干净的boot服务丢到服务网格中就自然了拥有了这些功能。这只是我暂时的一个理解等我学习了之后后续会再出一篇博客来讲解 2-2、微服务的目的 开始的开始我们用的是单体所有的代码都写在一个服务修改任何东西都是牵一发而动全身的不利于系统的稳定和快速的开发我理解这个就是微服务出现的目的。
上面讲了微服务会带来很多的问题从而需要引入很多新的组件来解决这些问题每一个组件都是一个新的技术。然后大家都被带偏了——去追求新的技术很长一段时间或许就是写这篇文章之前微服务在我的脑海里就等于各个组件。
所以我们疲于奔命学完一个又一个组件但心里却不承认微服务只觉得它很复杂给我们的开发带来了更多的问题而它的好处又体会不了太多。这是因为我们忽略的微服务最重要的是服务的拆分而不是这些个组件。
好吧其实大家不去学习服务拆分转而学各个组件这是对的。因为服务拆分很虚且和业务强相关面试也不问面试问的更多的还是各个组件。 三、微服务的拆分 讲道理我不太会微服务的拆分因为我刚刚才意识到服务拆分的重要性而服务拆分和业务强相关不像技术组件那么具体会与不会一眼鉴定。但我也可以讲讲我最近关于服务拆分的一点感悟。
以往我们的开发前后端产品这三个角色其实是很割裂的大家都忙各自的。然而要想让微服务拆分的好是需要这三方一起配合尤其是产品相当重要产品可以不懂技术但不可以不懂系统。
服务拆分有一个简单的点就是各个服务维护自己的表比如A服务想要获取B服务的数据一定是要B服务提供接口而不能是A服务去直接连B服务的表如果某个特别复杂的业务必须要连表才可以那就弄一个聚合服务出来对于各个服务的表的增、删、改一定要控制在自己的服务里。
每个服务经过一段时间的开发都相对稳定但新的服务也会一直有新服务总免不了要去查询旧服务的数据然而旧服务的增删改查早就准备好了接口都是现成的直接用即可。以前我老大告诉我这个的时候我说那得提供多少个接口啊现在看来还是太年轻。其实所需的接口不会很多有些表是不需要对外提供的
每个服务都只维护自己的数据跨服务去拿数据其实是有代价的产品要知道哪个数据属于哪个服务或者说是哪个模块而不能一股脑的觉得数据都在数据库随便拿随便组合如果是这样就会把系统做烂。 注使用dubbo看似和openFegin一样都是和本地一样的调用但实际上差别很大openFegin还是用的Http协议dubbo的性能要强很多。这就为组装数据提供了有力的帮助。 四、不连表查询 想想我们的系统真的有那么复杂吗报表不应该属于业务系统让报表去查业务系统它很容易导致数据库崩溃抛开报表我们的系统是不是就真的只有增删改查了
需要连表的地方也就只有列表和详细。
我们要把列表理解成展示某个资源的地方一个资源的数据应该存在一张表里面作如下思考
这个字段是否真的有必要在列表展示列表长度有限寸土寸金是否真的有人去看纵观阿里云控制台列表发现几乎没有一个列表让你可以不限制条件去搜索的搜索的时候真的需要模糊吗想一想作为系统的使用者假如有个通过用户手机号来搜索的功能你去哪里拿到用户一半的手机号如果真的有个别要展示其它服务的数据就通过rpc获取然后组装到列表中去字典数据统一先查询再通过内存匹配
再举一个实际的例子我们是做医疗系统的有一个很重要的数据“病人”所有的数据都是围绕这个病人来的大部人业务数据都冗余了病人的id但大部人业务的列表都要基于病人的手机号、唯一编号、姓名来查询我们是怎么做的呢
正常情况下我的第一反应就是 left join user 搞定如果是这样那你就多连了一张表而且这个user表在其它服务是没资格去访问它的我们提供一个三合一的Dubbo接口先通过这个接口返回病人的id再去业务表in这个id这样in的数据永远不会多 对于详情一个详情能展示多少个资源的信息呢千万不要让资源污染各个资源的数据放一起一个详情接口可以返回很多资源的数据但不应该放在一个实体里面应该是很多个实体。而每一个资源都是单表的查询。
所以聊下来全都是单表的查询会存在什么性能呢每一个数据的出入口都统一了不会出现乱拿数据的现象系统的维护性自然就高了。 这看起来一点也不简单实际上也非常的困难。需要上下齐心一致对每个角色的要求也很高。当然这并非不可实现我现在的公司就是这样实践的。 五、微服务的好处 按照上面的拆分后最大的一个好处就是写代码变得很简单了不会再有任何的性能问题也不存在什么困难的问题个人只需要当好螺丝钉好好的写自己的业务代码就好了幸福指数会很高。
它甚至比单体服务还要简单很多试想一下所有的操作都是单表的最多就是做一下数据的聚合这有多简单这个也不是百分百的好处相对连表就可以得出数据它需要多次的rpc来组合数据前期的开发会慢一些。 六、微服务的坏处 这里我只说个人的坏处它和好处是呼应的试想一下在这种环境下长时间的写代码你会有什么进步除非你是微服务的掌舵人。
看似代码变得很简单但它对人设计要求会高一些你提供的Dubbo接口是给别人用的你不能随意更改在设计阶段需要多思考。 最近公司的前端在做一个事情就是写Node作为聚合服务让Node去调用后台的A、B服务来做数据的聚合。这个好像也是阿里开创的如果只是简单的数据聚合为什么还要Java呢
而在不知多远的未来服务网格和无服务的到来之后Java不知是否还有用武之地。
不过也不必过于担心但就目前国内来讲大概率不会因为老板和甲方是不讲道的它们不懂微服务这会导致你压根无法拆分成微服务或者即便是拆分了也无法维护起来最终还是回归到了单体微服务虽然拆分成了多个服务实际上写的还是单体代码。
拆分不合理的微服务本质上就不是微服务它不但没有给你带来好处相反会带来很多的负担服务多入口乱七八糟的很难维护。 七、应付当下 人在江湖生不由己吃饭第一如果没办法说服业务方或者没有给力的团队也有一些很拙劣的办法来达到业务目的。
在连表到了极限的时候还可以尝试一些其它的办法。比如列表要展示是否关注公众号可以把这个字段冗余到主表里面每次用户关注/取消关注都实时去更新主表的字段。
具体的操作有两种方式
埋点在关注/取消关注的地方发出一个事件让线索服务感知然后去更新监控数据库本质上也就是监控binlog当数据库的这个字段发生了变动发出事件这个有很多的工具 比如 maxwell
这种方式也只能解决一对一的关系数据如果是一对多还是要连表来查询。但是我们同样可以洗表把N张表、洗成一张。
这种代价其实是很大的要维护数据的一致性。 另外一个相对好点的方式是用搜索引擎比如ES、MongoDB它们并非传统的关系型数据库数据扩展性相对高一些但依旧要面临数据的一致性问题。
