自己理解的分布式

用了一段时间的分布式,今天也稍微整理一下我理解的分布式,写个文章当做是自己的一个记录吧!
一、什么是分布式?
分布式是一个很笼统的东西,一个工作方式。一个程序或系统,只要运行在不同的机器上,就可以叫分布式。
说明白点就是"一个业务分拆多个子业务,可以部署在不同的服务器上"
以下如图,我列举了一个我工作中遇见的一个分布式项目结构。可能每个公司的架构不一样,但是这个不重要,重要的还是分布式架构的思想!有了这个我们才能在接下来的微服务浪潮中更愉快的玩耍哈。

分布式结构.png

二、分布式结构
当然仅凭一张个人理解的图,估计不能让大家看明白,这里就继续一一讲解一下。
图中,可以分为三个角色:消费者,服务协调者,服务提供者。
1.消费者:用java代码说,就是controller层。用MVC架构来说,包含了视图层和控制层。职能: 校验第三方传入的参数,调用相应的服务接口,返回给用户对应的视图。其他的事,没特殊情况就别再这层处理。
2.服务协调者:就是接口提供者提供的接口并给予消费者请求的接口。
3.服务提供者:这个是重点,也最复杂。原则上来说从数据库层,表的设计开始,每个模块的表和代码都是独立存在的。
三、重点讲解服务提供者
服务提供者,概念上来说,可以分为底层公共模块,业务模块,process跨模块层。
1.模块独立
模块之间相互独立,独立到哪一步呢?例如:我有两个模块,一个是商品模块一个是订单模块。商品模块有商品表和商品收藏表,订单模块有订单表和订单评价表,我现在有个需求,我要获取订单对应的商品名称,这个咋弄?可能有人会说,这还不简单,直接一个sql不就完了么?比方说:
select p.name from product p , order o where o.id = ?1 and p.id = o.product_id
正常来说一个简单的跨表查询就可以了,但是此时是分模块的,问题来了!模块是独立的,甚至连表我们也得当做为不同的数据库。比如商品表在A数据库,订单表在B数据库,数据库都不同你还怎么跨表查询? 所以说模块是独立的,除了一些底层的公共模块不能缺少,业务模块之间不管少了谁,也不会影响自己的业务正常进行。根据2/8原则我就能够把资源更多的放在我那个20%的业务上,加强子节点的性能,同时整个系统也能够协同工作。
2.底层共用
诸如redis,发短信,系统内部消息等等第三方功能以及调用频率极高的会员模块,此类功能模块都可以下沉到底层。被各个模块所引用,保证业务的正常运行。
3.跨模块调用
如上,刚刚说的想要获取订单对应的商品名,在不同的模块怎么办?此时process层就出现了,这个层可以组装各个service提供的接口,将不同模块的信息组装起来作为VO返回给前端。顺便提一下,这里涉及的一个概念。 比方查询一个分页数据怎么办?这里可以先查询数据源,然后遍历查询出来的列表,根据每一行对应的其他表的ID去查询组装相应的跨模块数据。意思就是我有10个订单列表,需要遍历十个订单,每次遍历都需要拿当前订单的商品ID去数据库查询对应的商品信息。可能有人会疑惑这样,我不就是查询了11次数据库么??其实不然,在大量数据下,没有外键远比有外键的设计高效。加之一般这种查询都会有索引,并且往往是在一个机房局域网内。所以即便是多次查询也远比关联查询来的高效。
4.高度服务化
写服务模块的一个重要原则就是"我就是一个提供服务的接口而已"。尽量不要在入参上代入判断分支条件的参数。我们要达到的目的就是,调用者只需要知道这个服务是干什么的,需要什么参数即可。而不需要让调用者再去判断比如一个
boolean 或枚举类型每个类型代表什么意思,给调用者带来跟多困扰。甚至有可能在第三方来当消费者的情况下,系统的可用性更一步降低。在文档缺失的情况下,更是灾难性的。所以,切记每一个接口都要明确自己提供的服务,不要混用。
5.不可信
当作为服务层开发者的时候,一定要明确一切外来的数据都是不可信的,明确自己是独立的存在!所以要适当的加上 参数的校验,以及相关逻辑的校验。确保做到即便接口被人为的错误调用,也能够保证正常流程。

四、优缺点
优点:
1.层次结构设计清晰,业务功能分明
2.面向服务化,对应消费者端很友好
3.一般遵循开闭原则,可扩展性,可维护性都比较不错
4.适合大型项目,给予不同的小组开发。并且降低人力成本。甚至服务层可以只交由少数核心人员开发,配置一些初级工程师即可完成大部分消费者端重复,简单的页面及逻辑。
5.代码可重用性强,不同的项目不需要重复的框架代码,不需要单独的部署项目。
6.分布式一般适用于大型项目,且开发质量一般比较高。架构设计和代码质量,项目规范一般都比较优良。
缺点:
1.复杂性更高,尤其是随着产品的横向扩展。表设计更复杂,很多性质一样的表,但是根据产品特性不同字段不一致。导致无论横表或者纵表设计,总会有一定的缺失。
2.部分服务治理框架不能热编译。比如我用的dubbo还未找到热编译的方式(或许存在,是我没找到),所以服务端的代码改动需要重新启动,花费时间长。连tomcat远程debug也用不了,让人更困扰。
3.编写一个好的分布式项目对设计人员要求更高,设计的差的项目从结构到代码给人的感觉都会比较差。
4.部署时间长,即便是脚本一键发布。但是代码上传服务器的网络传输,项目启动都会花费不少时间。
以上是自己理解的分布式概念,当然不同的公司方式肯定不一样,我所了解的也有限,本文仅供参考即可。而且真正的代码实现,从启动到API暴露,以及接口调用,版本迭代,业务升级,自动化发布等等都是更加的复杂,并且会有一定的改变,一个好的分布式项目远没想象中简单!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 201,312评论 5 473
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,578评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 148,337评论 0 333
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,134评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,161评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,303评论 1 280
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,761评论 3 393
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,421评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,609评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,450评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,504评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,194评论 3 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,760评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,836评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,066评论 1 257
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,612评论 2 348
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,178评论 2 341

推荐阅读更多精彩内容