工做也有几多年了,不管是身边遇到的仍是耳间闻到的,多多少少也积攒了本身的一些经验和思考,固然,博主并无太多接触高大上的分布式架构实践,相对比较零碎,随时补充(附带架构装逼词汇)。css
俗话说的好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的,固然对于咱们开发人员来讲,一个好的架构也不是一蹴而就的。html
开始的开始,就是各类框架一搭,而后扔到Tomcat容器中跑就是了,这时候咱们的文件,数据库,应用都在一个服务器上。
前端
随着系统的的上线,用户量也会逐步上升,很明显一台服务器已经知足不了系统的负载,这时候,咱们就要在服务器尚未超载的时候,提早作好准备。web
因为咱们是单体架构,优化架构在短期内是不现实的,增长机器是一个不错的选择。这时候,咱们可能要把应用和数据库服务单独部署,若是有条件也能够把文件服务器单独部署。
redis
为了提高服务处理能力,咱们在Tomcat容器前加一个代理服务器,我通常使用Nginx,固然你若是更熟悉apache也何尝不可。算法
用户的请求发送给反向代理,而后反向代理把请求转发到后端的服务器。spring
严格意义上来讲,Nginx是属于web服务器,通常处理静态html、css、js请求,而Tomcat属于web容器,专门处理JSP请求,固然Tomcat也是支持html的,只是效果没Nginx好而已。sql
反向代理的优点,以下:数据库
基于以上Nginx反向代理,咱们还能够实现动静分离,静态请求如html、css、js等请求交给Nginx处理,动态请求分发给后端Tomcat处理。apache
Nginx 升级到1.9.5+能够开启HTTP/2.0时代,加速网站访问。
固然,若是公司不差钱,CDN也是一个不错的选择。
在这分布式微服务已经广泛流行的年代,其实咱们不必踩过多的坑,就很容易进行拆分。市面上已经有相对比较成熟的技术,好比阿里开源的Dubbo(官方明确表示已经开始维护了),spring家族的spring cloud,固然具体如何去实施,不管是技术仍是业务方面都要有很好的把控。
服务拆分之后,随着而来的就是持续集成部署,你可能会用到如下工具。
Docker、Jenkins、Git、Maven
图片源于网络,基本拓扑结构以下所示:
整个持续集成平台架构演进到以下图所示:
Linux集群主要分红三大类( 高可用集群, 负载均衡集群,科学计算集群)。其实,咱们最多见的也是生产中最常接触到的就是负载均衡集群。
你们都知道,服务通常分为有状态和无状态,而分布式sessoion就是针对有状态的服务。
Session Replication 方式管理 (即session复制)
简介:将一台机器上的Session数据广播复制到集群中其他机器上
使用场景:机器较少,网络流量较小
优势:实现简单、配置较少、当网络中有机器Down掉时不影响用户访问
缺点:广播式复制到其他机器有必定廷时,带来必定网络开销
Session Sticky 方式管理
简介:即粘性Session、当用户访问集群中某台机器后,强制指定后续全部请求均落到此机器上
使用场景:机器数适中、对稳定性要求不是很是苛刻
优势:实现简单、配置方便、没有额外网络开销
缺点:网络中有机器Down掉时、用户Session会丢失、容易形成单点故障
缓存集中式管理
简介:将Session存入分布式缓存集群中的某台机器上,当用户访问不一样节点时先从缓存中拿Session信息
使用场景:集群中机器数多、网络环境复杂
优势:可靠性好
缺点:实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入
负载均衡策略的优劣及其实现的难易程度有两个关键因素:1、负载均衡算法,2、对网络系统情况的检测方式和能力。
一、rr 轮询调度算法。顾名思义,轮询分发请求。
优势:实现简单
缺点:不考虑每台服务器的处理能力
二、wrr 加权调度算法。咱们给每一个服务器设置权值weight,负载均衡调度器根据权值调度服务器,服务器被调用的次数跟权值成正比。
优势:考虑了服务器处理能力的不一样
三、sh 原地址散列:提取用户IP,根据散列函数得出一个key,再根据静态映射表,查处对应的value,即目标服务器IP。过目标机器超负荷,则返回空。
四、dh 目标地址散列:同上,只是如今提取的是目标地址的IP来作哈希。
优势:以上两种算法的都能实现同一个用户访问同一个服务器。
五、lc 最少链接。优先把请求转发给链接数少的服务器。
优势:使得集群中各个服务器的负载更加均匀。
六、wlc 加权最少链接。在lc的基础上,为每台服务器加上权值。算法为:(活动链接数*256+非活动链接数)÷权重 ,计算出来的值小的服务器优先被选择。
优势:能够根据服务器的能力分配请求。
七、sed 最短时间望延迟。其实sed跟wlc相似,区别是不考虑非活动链接数。算法为:(活动链接数+1)*256÷权重,一样计算出来的值小的服务器优先被选择。
八、nq 永不排队。改进的sed算法。咱们想一下什么状况下才能“永不排队”,那就是服务器的链接数为0的时候,那么假若有服务器链接数为0,均衡器直接把请求转发给它,无需通过sed的计算。
九、LBLC 基于局部性的最少链接。均衡器根据请求的目的IP地址,找出该IP地址最近被使用的服务器,把请求转发之,若该服务器超载,最采用最少链接数算法。
十、LBLCR 带复制的基于局部性的最少链接。均衡器根据请求的目的IP地址,找出该IP地址最近使用的“服务器组”,注意,并非具体某个服务器,而后采用最少链接数从该组中挑出具体的某台服务器出来,把请求转发之。若该服务器超载,那么根据最少链接数算法,在集群的非本服务器组的服务器中,找出一台服务器出来,加入本服务器组,而后把请求转发之。
MySql主从配置,读写分离并引入中间件,开源的MyCat,阿里的DRDS都是不错的选择。
若是是对高可用要求比较高,可是又没有相应的技术保障,建议使用阿里云的RDS或者Redis相关数据库,省事省力又省钱。
若是有搜索业务需求,引入solr或者elasticsearch也是一个不错的选择,不要什么都塞进关系型数据库。
引入缓存无非是为了减轻后端数据库服务的压力,防止其"罢工"。
常见的缓存服务有,Ehcache、OsCache、MemCache、Redis,固然这些都是主流经得起考验的缓存技术实现,特别是Redis已大规模运用于分布式集群服务中,并证实了本身优越的性能。
异步通知:好比短信验证,邮件验证这些非实时反馈性的逻辑操做。
流量削锋:应该是消息队列中的经常使用场景,通常在秒杀或团抢活动中使用普遍。
日志处理:系统中日志是必不可少的,可是如何去处理高并发下的日志确是一个技术活,一不当心可能会压垮整个服务。工做中咱们经常使用到的开源日志ELK,为嘛中间会加一个Kafka或者redis就是这么一个道理(一群人涌入和排队进的区别)。
消息通信:点对点通讯(我的对我的)或发布订阅模式(聊天室)。
消息队列中提到的ELK开源日志组间对于中小型创业供公司是一个不错的选择。
以上种种,没有安全作保证可能都会归于零。
Linux(必备)、某软的
DNS、F五、LVS、Nginx、OpenResty、HAproxy、负载均衡SLB(阿里云)
Dubbo、Motan、Spring-Could
DRDS (阿里云)、Mycat、360 Atlas、Cobar (不维护了)
RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka
Zookeeper、Redis
Redis、Oscache、Memcache、Ehcache
Docker、Jenkins、Git、Maven
OSS、NFS、FastDFS、MogileFS
MySql、Redis、MongoDB、PostgreSQL、Memcache、HBase
专用网络VPC、弹性公网IP、CDN