架构师之路--应用架构的选型和dubbo

小时候总是跟妈妈着去上班。妈妈是儿科医生。有一天来了一个妈妈带着他的宝宝挂了妈妈的专家号。宝宝长得很可爱,但是脸上没有任何表情,脑袋很大,四肢和刚出生的宝宝一样大。妈妈抬起宝宝的四肢,一放手它又耷拉回去。妈妈说话声音很沉重,说我直接给你开个证明吧,你可以再要一个孩子。那个妈妈一句话都没说,只是坐在那里抱着她的宝宝。这个妈妈在化工厂工作,天天和染料打交道。这已经不是她的第一个宝宝了,每个宝宝命运都差不多。这个妈妈的绝望和医学无关。所以高考的时候,怎么都不肯听妈妈的。自己报了计算机。妈妈知道后让我去找老师改回来。我走到半路给妈妈买了件衣服就回来了。妈妈虽然还是很想让我学医,但是看到我买的衣服显然很高兴,也明白她是拗不过我的,只好作罢。

这个选型主要决定于系统复杂度。先回顾一下。

  1>单一应用架构:对于一个流量很小的网站来说,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。之前在上家公司做过一个微信公众号的开发就是基于这种架构,我和一个大牛的前端架构师两个人就是一个项目,还是挺happy的。但是这种架构其实用java的成本有点高,用PHP更快。所以我自己接了个私活做个类似携程+如家的网站用的就是php。

  2>垂直应用架构:访问量再大一点,可以将应用拆成互不相干的几个应用,以提升效率。8年前刚进人人网的时候用的就是这个架构。因为是社交网站,被拆分成了SNS,UGC,各个游戏等子模块。

  3>分布式服务架构:垂直应用多了,交互不可避免,将核心业务抽取出来作为独立的服务,形成稳定的服务中心。大概从11年起,人人网逐渐采用这种架构。随之而来的是采用一些技术,记得最初也采用过RMI的,都是内部调用,防火墙也应该不是问题。但是后来hession和thrift开始流行,我们又进行了这方面的尝试。zookeeper用作注册中心,主要是配置管理方面。

  4>流动计算架构:当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需要增加一个调度中心基于访问压力实时管理集群容量,资源调度和提高集群利用率。

  Dubbo是Alibaba开源的分布式服务框架,按照分层来架构,使各个层之间解耦合。在我们项目中,作为服务层和业务层的桥梁来使用。Dubbo层可以用servlet容器启动,也可以直接用main函数直接加载ApplicationContext。总之,dubbo是依赖于spring来管理的。Dubbo框架设计共划分了10层。其中服务接口层,配置层,服务代理层是开发需要自行写入的,用法自行百度。

下面说一下服务注册层。它以服务URL为中心,扩展接口为RegistryFactory,Registry和RegistryService。打开RegistryFactory的源码可以看到,这是一个SPI的,核心工作就是取得其注册的信息。内部实现类是DubboRegistryFactory。作用就是根据url从一个本地的concurrenthashmap中取出其注册信息,如果注册信息不存在,则创建一个。同时将此注册目录加入集群。这种concurrenthashmap的东西要返回视图,返回的一般都是一个unmodify的拷贝。Dubbo里为了减少对apache的依赖,用的是java.util里的Collections.unmodifiableCollection。

集群层。这一层是上面提到的流动架构的体现。封装多个提供者的路由及负载均衡,并桥接注册中心,以Invoker为中心,扩展接口为Cluster,Directory,Router和LoadBalance。从SPI的配置文件来看,支持4种常用的负载均衡

random=com.alibaba.dubbo.rpc.cluster.loadbalance.RandomLoadBalance

roundrobin=com.alibaba.dubbo.rpc.cluster.loadbalance.RoundRobinLoadBalance

leastactive=com.alibaba.dubbo.rpc.cluster.loadbalance.LeastActiveLoadBalance

consistenthash=com.alibaba.dubbo.rpc.cluster.loadbalance.ConsistentHashLoadBalance

具体类里基本都是算法的实现,可以不用看了。Cluster支持的算法如下:

mock=com.alibaba.dubbo.rpc.cluster.support.wrapper.MockClusterWrapper

failover=com.alibaba.dubbo.rpc.cluster.support.FailoverCluster

failfast=com.alibaba.dubbo.rpc.cluster.support.FailfastCluster

failsafe=com.alibaba.dubbo.rpc.cluster.support.FailsafeCluster

failback=com.alibaba.dubbo.rpc.cluster.support.FailbackCluster

forking=com.alibaba.dubbo.rpc.cluster.support.ForkingCluster

available=com.alibaba.dubbo.rpc.cluster.support.AvailableCluster

mergeable=com.alibaba.dubbo.rpc.cluster.support.MergeableCluster

broadcast=com.alibaba.dubbo.rpc.cluster.support.BroadcastCluster

监控层:RPC调用次数和调用时间监控,以Statistics为中心,扩展接口为MonitorFactory, Monitor和MonitorService。实现上和注册层的实现是一样的。

远程调用层:封装RPC调用,以Invocation和Result为中心,扩展接口为Protocol,Invoker和Exporter。Protocal是服务域,它是Invoker暴露和引用的主功能入口,负责Invoker的生命周期管理。Invoker是实体域,它是Dubbo的核心模型,其他模型转换成它。它代表一个可执行体,可向它发起invoker调用,它有可能是一个本地实现,也可能是一个远程的实现,也可能是一个集群实现。相信了解过java动态代理的话,这个不难理解。

信息交换层:封装请求响应模式,同步转异步,以Request和Response为中心,扩展接口为Exchanger,ExchangeChannel,ExchangeClient和ExchangeServer。

网络传输层:抽象mina和netty为统一接口,以Message为中心,扩展接口为Channel,Transporter,Client,Server和Codec。

数据序列化层:可复用的一些工具,扩展接口为Serialization,ObjectInput,ObjectOutput和ThreadPool。

 可以以dubbo配置项的解析为入口跟进源码。在dubbo jar包下META-INF里面的spring.handlers里,有自定义的spring命名空间处理器,可以找到对应的java类。dubbo的引入不可避免的带来IO,像咱们写代码的,这儿压缩几个字节,那儿解开一个循环,这些代码优化可能轻易就被低效的IO所抵消。IO操作比在内存中进行数据处理所需的时间一般长20倍。前段时间用CAT做性能监控就发现,如果没有dubbo层大概几ms的操作,引入dubbo执行时间正常都在几百ms。所以SOA要谨慎。要懂一些底层原理的话,其实架构的选择就能少些纠结,看各种框架也能马上就明白。网友问我在读什么书,其实现在很少有时间读,开放平台项目进入联调阶段了,还有很多细节可以优化的地方,还是挺忙的。之所以看到我的文章乱序严重也是因为我是用特别零散的时间来写的。但是前段时间不是看了<netty in action>嘛,看这本书就不得不再看看<java nio>做一下对比,看了<java nio>呢,里面作者又推荐读一下《操作系统第六版》,话说我大学也是计算机的,但是这本书还是需要重新看一遍的。每本书作者都会引入一些相关的好书,所以我的书单永远空不了。

  dubbo底层不管是用mina也好,netty也好,IO原理都是一样的。比如和底层相关的,之前我也提到我曾经自己分析过图片的二进制流来获取图片翻转信息。在这个过程中我了解到和底层操作系统相关的两个标准,Intel标准和摩托罗拉标准。分别对应两种字节顺序:大端字节顺序和小端字节顺序。了解这个对于nio的缓冲区也有帮助。而通道不是分为单工,双工,半双工嘛。面向流的socket肯定是双工的,所以流在网络中请求和响应的读写操作才可以同时进行。而像文件IO这样的,读写肯定是分离的,单工进行的。

上周有人问我我们的项目使用缓存和数据库就能解决问题,为啥要开发一个搜索引擎,考虑问题的角度不是应该放在数据分析上吗?我表示同意他的观点,因为我自己没组织好语言说服不了人家的时候我都是这个态度。实际上,首先说我们已经分析出来了,瓶颈就在缓存上了。缓存采用memcached也是缓存,redis也是缓存。实际上solr也是缓存啊!这种缓存是基于多维数据结构的获取,合适我们的项目也合适很多列表带维度的项目。我认为以后是很有前景的。而solr或者说es或者说dubbo或者memcached或者redis面临的问题都是一样的,性能嘛,而性能最大的消耗点就是io。我们项目用的dubbo+缓存。是两次跨网络的io。dubbo解决的是服务复用的问题,缓存解决的是空间换时间的问题,搜索引擎可以做为一个独立的服务一次io同时解决这两个问题,我为啥让人家明白不了呢

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

Golang语言零基础入门资料整理

GO语言跟它名字一样是门比较装逼的语言,鲜有菜鸟初学者教程,所以没有语言基础的话,理解起来会有点困难。闲来没事整理了一个GO零基础入门资料。 安装与简介 因为国...

4446
来自专栏架构师之旅

3个面试中遇到的问题《JAVA面试题》

面试官:“一个http 请求,接受json数组,数组内容是id,返回用户信息,在测试上是ok的,到预生产就报错了,可能是什么问题?” 我想了想说:“代码一致吗?...

8745
来自专栏CDA数据分析师

一个 Pythoner的 Awesome List

? 从大三接触 Python 到现在几乎已经有两年的接触经验了,除去中间有一年左右接私活写写 Android 和 Lamp 之外,有 Python 实际项目开...

2776
来自专栏圣杰的专栏

eShopOnWeb 知多少

eShopOnWeb是基于ASP.NET Core构建,官方创建这样一个示例项目的目的,我想无非以下几点:

1771
来自专栏精讲JAVA

关于淘点点面试中碰到的架构问题​

之前面试淘点点的时候被问倒得一个问题至今牵挂,由于工作环境的限制,我没能接触到一些大数据量的并发工作,也没能有机遇参与复杂系统的设计,而我学习复杂或高并发系统的...

1123
来自专栏斑斓

软件系统的稳定性

软件系统的稳定性,主要决定于整体的系统架构设计,然而也不可忽略编程的细节,正所谓“千里之堤,溃于蚁穴”,一旦考虑不周,看似无关紧要的代码片段可能会带来整体软件系...

1.1K6
来自专栏大数据和云计算技术

新数仓系列:MongoDB关键能力和特性梳理

最近看一本书,铃木敏文的《零售的哲学》,里面提到一个很有意思的观点,711核心使命是提供便利,围绕便利场景,提供一系列食品、ATM服务等,而不是和超市去PK货物...

3106
来自专栏牛客网

金山wps服务端二面面经

前言:阿婆主很久很久没写过面经了,之所以写这篇面经是真的感觉wps相关的面经太少啦,既然有机会面试那就写一篇吧 直接上啦---> 协程和线程,比如协程底层的实现...

5836
来自专栏Golang语言社区

Node.js真的无所不能?那些不适用的应用领域分析

Node.js是一个服务器端JavaScript解释器,底层采用的还是libevent;它的目标是帮助程序员构建高度可伸缩的应用程序,目前对Node.js 的采...

36310
来自专栏程序人生

再谈 API 的撰写 - 契约

现代社会是个契约社会,生活中大大小小的事情都在和契约打交道。去奥莱买件衣服,一纸小票,便是你跟商家的契约:你花钱买到了产品,产品的问题商家会承诺处理(退换货)。...

3838

扫码关注云+社区

领取腾讯云代金券