cover

  • 之前给研发的小可爱们做过一次关于架构方面的分享,觉得当时一些架构的东西没有讲清楚,所以再做一些整理。
  • 现在在写的新版的云家园的后端,打算采用微服务的架构,在这普及一下微服务。
    • 在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微"、什么是"服务", 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释(2 pizza 团队最早是亚马逊 CEO Bezos提出来的,意思是说单个服务的设计,所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 )。 而所谓服务,一定要区别于系统,服务一个或者一组相对较小且独立的功能单元,是用户可以感知最小功能集。
    • 来自博客
  • 就现在的新版云家园来说,他是一个系统,学生学工管理系统,而里面的诸如考试,宿舍,学生资助,值班考勤,是一个个服务,服务的路由,就是用户能够感知到的最小功能。
  • 说完了微服务的定义,来说一下为什么作微服务,无非是两点 解耦和安全。先理解一下耦合度的概念:
    • 耦合性(英语:Coupling,dependency,或称 耦合力 或 耦合度)是一种软件度量,是指一程序中,模块及模块之间信息或参数依赖的程度。
    • 来自百度
  • 就像你们现在写的模块,直接堆砌在之前写的架构上面,然后会导致你们程序中用到很多老田程序中创的表,写的函数,会把之前的那一部分代码逻辑加到你们的程序中去,导致你们写的代码严重依赖于如今有的程序和如今的表结构,如果以后核心表结构发生了变化,比如分库分表了,你们难道还有去手动改你们的sql做分库分表的兼容吗(分库分表在可预见的未来里是一定会有的),这就代表了这个程序是严重耦合的。
  • 然后说一下安全问题,如果现在的这个云家园完成了,然后上线了,然后其中的一个服务崩了,之前向王榕了解了一下spring是每个请求会向线程池请求一个线程,如果这个线程阻塞了,碰上流量高峰,这个请求的访问量很大,会导致线程池中的所有的线程都被阻塞,整个服务宕机。这里我们理解一下云家园的流量模式,现在我们学校目前在用的云家园我觉得有这样的模式,平时存在一定的流量,然后在某些特定的时间会出现流量高峰,也就是类似与这样的存在,设想一下如果在尖峰时期发生了这样的事故,那么后果是很严重的。

    尖峰

  • 还有一点就是缓存。我之前在云家园留下了一份文档,是关于redis缓存的,里面写了目前缓存使用过的键名,一个大系统的缓存一定是不容易维护的,特别是像我们这样业务相近,多人开发的情况,很容易出现缓存键名冲突的bug,就是类似于“谁动了我的奶酪”:测试没问题,上线出bug, 排查下来代码逻辑也没有问题,然后一段时间又好了,一段时间又出bug,这会耗费很多时间去排查。

  • 补充一点就是长的sql特别难以优化,特别是这种各种join和子查询满天飞的,遗憾的是,mysql对于子查询和join的支持并不是很好,给你们看一下:

    • join查询
    • 子查询

    这两句sql的效果是一样的,但是explain以后,你就会发现这两句sql有很大的差别。我可以给你们看一下explain的结果

    第一句使用了临时表和排序加一个全表扫描, 第二句使用了额外的驱动表,由于数据量不大所以也无法直观的看出问题, 但是要知道,临时表上没有索引,排序当数据量大的时候会使用额外的磁盘排序。

  • 而且,你们不觉得如果就这样写不就是换种语言再堆一遍业务逻辑吗。。。这难道不无聊吗。。
  • 反正我现在天天在这写逻辑一点意思都没有。
  • 然后来说一下我打算把新版云家园做成的微服务的样子
    • 首先,除了对外提供rpc接口的服务,其他服务是不能对“主数据库”进行访问的,这里主数据库有引号是因为你们的数据表还是再同一个数据库里面,但是你不能够操作其他应用创建的表,所以对你的应用而言就是一个新的数据库,不过drop all这种操作还是不允许的。
    • 然后说一下redis缓存的事情,这个由于阿里云上有很多redis的数据库,所以应用都是分配两个,一个做缓存,一个做存储,只需要缓存的那就申请一个就好了,这样就不存在冲突的问题了,除非是你自己写的。
    • 最后是获取和存放数据的问题,获取基本信息数据统一通过内网rpc接口,会对外网提供测试接口, 然后应用产生的信息存放在自己的数据表中,至于基本信息呢,可以存放也可以不存放,存放的推荐放缓存,设置过期时间,但绝对不要把基础信息作为主要数据存放, 10个字段有一两个做数据冗余就好了,不然更新了容易出bug。
  • 然后说一下微服务的缺点,或者是我现在所想的微服务的缺点
    • 第一点就是缓存浪费,因为所有的缓存库隔离,导致基础缓存不能很好的使用,解决这个点的办法是做rpc服务端的缓存,但是这样会降低时效性,所以建议将热点数据的缓存时间设置的短一点,将固定数据的缓存时间设置的长一点,当然应用初期是不存在所谓的固定数据的。
    • 第二点是作为你们写的应用,会加杂一些额外的逻辑进去,会增加你们写的应用的逻辑复杂性,但是这点是可控的,因为你们可以通过设计你们业务表来降低你们应用的复杂性,这对你们来说是一个挑战。
  • 做成微服务后可以很方便的变成分布式,似乎这两个词总是同步出现的,很长的一段时间里面,你们也会有事情去完成,我们会为你们尽力去争取服务器的资源,所以,别去一味的堆砌逻辑了,那就是搬砖啊。
  • 拿今天早上看见的一篇文章来说,有些人为什么游戏玩的好,因为他们有意识,什么时候队友会来支援,什么时候可以上,什么时候应该做什么,写代码也是一样的,也是要有意识,我这一段代码写出来要达到什么效果,我的整个架构要是什么样子,我的应用的延迟要控制在多少时间。
  • 掷地有声,才能必有回响。

扫描二维码,分享此文章

wujintao's Picture
wujintao