最近一直在做一个电商项目,需要把原有单系统架构的项目,改造成基于服务的架构,SOA。
有点挑战,做完了,会有很大进步。
上一篇,我们描述了原有项目中的问题。
或者说是,本篇的基本背景。
本篇开始,给出我们的改进方案和技术架构。
不过,根据自己的理解,我先列出了“规范和约定”。
因为,我认为“规范和约定”是具体方案和解决办法的基石,也是很多互联网项目的基本准则吧。
2.改进方案和技术架构
上一篇,我们描述了原有项目中的问题。
或者说是,本篇的基本背景。
本篇开始,给出我们的改进方案和技术架构。
不过,根据自己的理解,我先列出了“规范和约定”。
因为,我认为“规范和约定”是具体方案和解决办法的基石,也是很多互联网项目的基本准则吧。
2.改进方案和技术架构
2.1规范和约定
2.1.1代码规范
用准确的英文单词,给类、函数名、变量名
get,add,update
更多细节,参考“
Java代码规范-小雷.pdf
”和“
JAVA编码规范.pdf
”
2.1.2约定优于配置,约定优于注释
数据库表名和字段名、Java类、函数、变量名
约定优于配置
约定优于配置(convention over configuration),也称作按约定编程,是一种软件设计范式,
旨在减少软件开发人员需做决定的数量,获得简单的好处,而又不失灵活性。
本质是说,开发人员仅需规定应用中不符约定的部分。
例如,如果模型中有个名为Brand的类,那么数据库中对应的表就会默认命名为brand,Controller的名字默认命名为BrandController。
只有在偏离这一约定时,例如将该表命名为"product_brand",才需写有关这个名字的配置。
约定优于注释
这个是我自己的见解。
用标准,统一的英文单词,给变量和函数等命名。
比如数据库表brand表有个字段name。
BrandDao有个add和update方法。
brand:就是品牌的意思
name:就是品牌的名称
add:就是增加一个品牌,BrandDao中,千万别用addBrand这种啰嗦的命名方式,类名中已经包含了Brand,里面的dao就是和brand相关的。
update:就是更新一个品牌
不用去写注释,也不用去和相关人士,过多解释这个字段的意思,这个函数的作用。
望文生义,通过名字就可以知道准确的意思,就不用多费口舌了。
对于那些复杂的代码,比如订单支付过程中,有一些不好理解的业务逻辑代码,再写简洁的注释。
约定优于注释
这个是我自己的见解。
用标准,统一的英文单词,给变量和函数等命名。
比如数据库表brand表有个字段name。
BrandDao有个add和update方法。
brand:就是品牌的意思
name:就是品牌的名称
add:就是增加一个品牌,BrandDao中,千万别用addBrand这种啰嗦的命名方式,类名中已经包含了Brand,里面的dao就是和brand相关的。
update:就是更新一个品牌
不用去写注释,也不用去和相关人士,过多解释这个字段的意思,这个函数的作用。
望文生义,通过名字就可以知道准确的意思,就不用多费口舌了。
对于那些复杂的代码,比如订单支付过程中,有一些不好理解的业务逻辑代码,再写简洁的注释。
2.1.3单表
a.服务分离
web服务比较多,到处都是, 一个服务和对应的数据库是逻辑上在一起的。
感觉有点说不通呢?多表凭啥不能做到“服务分离” 。
更准确的理由,应该是下面提到的“分库分表”,然后才是“服务分离”这个 。
web服务比较多,到处都是, 一个服务和对应的数据库是逻辑上在一起的。
感觉有点说不通呢?多表凭啥不能做到“服务分离” 。
更准确的理由,应该是下面提到的“分库分表”,然后才是“服务分离”这个 。
b.不方便缓存
单表的结果集,方便缓存,而多表则不合适。
比如user表有roleId字段,查询用户的时候,查1个用户,再根据roleId查角色信息。
但是,关联的角色名称可能变化了,或者user用户信息变了,而角色不变。
那么,可以单独缓存user或者role。
而多表的情况下,还是都查询了数据库。
单表的结果集,方便缓存,而多表则不合适。
比如user表有roleId字段,查询用户的时候,查1个用户,再根据roleId查角色信息。
但是,关联的角色名称可能变化了,或者user用户信息变了,而角色不变。
那么,可以单独缓存user或者role。
而多表的情况下,还是都查询了数据库。
c.联合查询,效率低
当数据量大的时候,笛卡尔积很大,10000*10000,占用的内存很大。
假设内存足够的话,笛卡尔积的过程,也很需要时间。
而单表查询,没有笛卡尔积的过程,先批量查A,比如10条,再批量去B查,1次10条,代码组装,数据就够了。
这里面存在一个问题,当A-B表关联查询,但是查询条件是B表字段的时候,这个是否必须“关联查询”。
比如,根据用户角色名称,查询用户,获得第1页10条数据。
如果还是单表的情况,就需要做“冗余”。
因此,我们说“单表”存在2个含义。
一、只有自己一个表的数据,二、物理上是一个表,但逻辑上有2个表的数据。
当数据量大的时候,笛卡尔积很大,10000*10000,占用的内存很大。
假设内存足够的话,笛卡尔积的过程,也很需要时间。
而单表查询,没有笛卡尔积的过程,先批量查A,比如10条,再批量去B查,1次10条,代码组装,数据就够了。
这里面存在一个问题,当A-B表关联查询,但是查询条件是B表字段的时候,这个是否必须“关联查询”。
比如,根据用户角色名称,查询用户,获得第1页10条数据。
如果还是单表的情况,就需要做“冗余”。
因此,我们说“单表”存在2个含义。
一、只有自己一个表的数据,二、物理上是一个表,但逻辑上有2个表的数据。
d.
并发
每个表数据量、查询查询、修改次数等都不一样。
单个表,如果需要锁住一行,也更加精准。
这个地方,还不是特别确定。
单表锁一行:select * from brand where id =1 for update
多表锁一行:select * from user left join role on user.roleId = role.id where roleId = 1 for updte ?
准确的说,以上是“并发修改” 中的1个例子,还有“并发查询”等很多种并发场景吧。
每个表数据量、查询查询、修改次数等都不一样。
单个表,如果需要锁住一行,也更加精准。
这个地方,还不是特别确定。
单表锁一行:select * from brand where id =1 for update
多表锁一行:select * from user left join role on user.roleId = role.id where roleId = 1 for updte ?
准确的说,以上是“并发修改” 中的1个例子,还有“并发查询”等很多种并发场景吧。
e. 如何分表、分库
数据量大的时候,需要分表分库。
分表分库之后,联合查询就很废材了。
数据量大的时候,需要分表分库。
分表分库之后,联合查询就很废材了。
f.根据业务场景和特性,分别做优化
实际情况,user、role、brand等查询量、修改量等都是不同的。
这一点,和把整个项目拆分成商品product、用户user等思想是类似的。
拆分成更小粒度的,方便做优化。
疑问: 既然MySQL多表这么废材,为什么当初设计MySQL等数据库的时候,都有关联查询等一大堆功能特性呢?
难道是因为互联网崛起,超出了当初设计者的想象力?
这一点,和把整个项目拆分成商品product、用户user等思想是类似的。
拆分成更小粒度的,方便做优化。
疑问: 既然MySQL多表这么废材,为什么当初设计MySQL等数据库的时候,都有关联查询等一大堆功能特性呢?
难道是因为互联网崛起,超出了当初设计者的想象力?
2.1.4单一职责
一个类、一个函数,只做一件事,只完成一个功能。
一个接口集,对外提供的服务,也是紧密相关的。
个人观察:多问几个为什么,可以发现更多的问题,学到更多更深入的“知识点” 。
用单表是好,为啥不能用“多表联合查询” ,通过对这个问题的思考和交流,理解更近了一步。
约定优于注释,算是我的独家见解吧~
一个接口集,对外提供的服务,也是紧密相关的。
个人观察:多问几个为什么,可以发现更多的问题,学到更多更深入的“知识点” 。
用单表是好,为啥不能用“多表联合查询” ,通过对这个问题的思考和交流,理解更近了一步。
约定优于注释,算是我的独家见解吧~