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

Posted 2020-09-21 编程一生

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

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

 

　　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支持的算法如下：

 

1

2

3

4

5

6

7

8

9

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同时解决这两个问题，我为啥让人家明白不了呢