标签：获取 不同 uac 存储 检测服务 keepalive 导致 遇到 缺点
开头的话，架构多半和业务关联在一起，如果只是简单的图书管理系统、选课系统或者什么简单的财务系统，用不着分布式。只有大型公司、高并发的业务才需要分布式的帮助。当然，架构本身要和业务模型紧密配合才能发挥作用。
很长一段时间，java都是最流行的编程语言。我想，一方面是由于java可以用来开发网站后端程序，另外一方面java可以用来开发android这样的客户端程序。当然，很多人会说，java天生具有网络属性，具有很好的分布式基因。这应该是一种认知错误。所谓的分布式都是基于tcp/ip网络，它发展的原因是因为稳定性、性能和业务扩展的需要，单台服务器已经远不能满足业务的需要。这方面，其他语言也可以做到这一点，比如说python、go、erlang等等。只是，对于企业来说，一个不可忽略的现实是，市场上合格的java工程师很多，但是可以独当一面的python、go、erlang工程师太少，这也使得一些企业即使在创立初期的时候用了其他编程语言，后期也会慢慢转到java上面。不是技术不允许，实在是人才不允许。脚本语言太自由，坑太多，稍不小心就有可能埋雷，而java语言规范、第三方库多，即使有错误，也会很快暴露出来，这也算java很好的一个优势吧。
说到网站后端开发，很多人都会选择java + Spring + myBatis的开发模式。这无可厚非。只是随着业务的快速发展，整体的网站架构也在快速迭代当中，不妨利用这段时间简单梳理一下发展流程。
1、单台服务器模式
所谓的单台服务器，就是http服务器软件、静态文件（主要是以图片为主，还有html、css、js文件）、mysql软件安装在一台服务器上。很多大学里面的课程作业都是这么设计的。
2、多台服务器模式
当文件越来越多的时候，单台服务器远远不能支撑业务的发展。这个时候会将http服务器软件、文件服务器、数据库软件安装在不同的服务器上面，彼此之间用tcp/ip进行连接，企业内部的宽带要比外面买的宽带速度高很多。
3、添加缓存服务器
随着业务的发展，用户对数据的速度要求越来越高，要是每次访问的时候都直接访问数据库，这个效率其实是很低的。在现实场景中，大家会发现读数据的请求比改数据的请求要多的多，所以这个时候添加一些nosql缓存服务器，可以有效地提高用户体验。
4、反向代理服务器
单台http服务器的性能总是有限的，所以实际业务场景下一般会使用nginx作为代理服务器。通过代理软件，用户的数据请求会被均衡分配到不同的http服务器上面。当然此时nginx就成了系统的瓶颈点，所以为了保护nginx，一般也会安装多台nginx服务器，使用keepalive软件来保证nginx宕机的时候自动进行切换。
5、CDN服务器
大家如果安装过不同电信运营商的宽带就知道，一个电信运营商下的pc如果访问另外一个电信运营商的服务器，速度是很慢的。所以一个比较务实的方法，就是讲常用的文件、特别是静态文件安装在离用户最近的那台运营商服务器上面，这就是CDN服务器设计的初衷。
6、分布式文件服务器
如果网站后台文件过多，那么单台服务器远不能满足用户的要求，这个时候分布式文件服务器应运而生。
7、分布式数据库服务器
同样的，当数据累积到一定程度的时候，单台服务器其实远远不能满足要求。而且，单台服务器还比较危险，一旦服务器宕机之后，后果其实是不堪设想的。这个时候一般会有两种方案，一种是分库分表，即将数据库分布在不同的服务器上面，或者将同一张表的内容分布在不同的服务器上面，插件可以帮助我们做到这一点，比如MySql Proxy；另外一种方法就是真正的分布式数据，比如TiDB，这个时候用户不需要关心数据是怎么分配的，因为底层软件就可以将数据灵活的存储在不同的服务器上面。每种方法都有自己的自己的优缺点，大家可以灵活应对。
8、微服务部署
从前的代码部署都是安装在http服务器上面，但是一旦某一个小功能失败，那么有可能会导致整台http服务器失败。所以，针对这种情况，现在提出了一种微服务器的模式。它的基本思想类似于rpc，http服务器从nginx接收到用户的请求之后，不是直接运行，而是通过rpc向微服务器提出请求，并且等待微服务的结果。微服务中的服务，其实就是一个一个小的业务。单个微服务未必是一台服务器，也有可能是基于zookeeper的多台服务器，因为数据量或大或小，不一定。
9、消息服务器
不同的服务器之间是需要进行数据沟通的。为了性能，很多时候，服务器之间的通信都是异步的，所以消息服务器就充当了缓冲和信息处理的功能。消息服务一般是周期处理、或者满足一定业务条件就会触发处理。微服务之间的通信，就需要消息服务器的帮助。
10、监控服务器
服务器运行过程中会出现各种各样的情况。服务器cpu多少、ram还剩多少、存储怎么样、宽带用了多少、当前跑了哪些业务，这些信息都需要有一个监控服务器来完成。
11、运维服务器
当产品开发好，这个时候一般会在小范围内进行部署，也就是小范围的发布。等到没有大的问题之后，就会进行大范围的推送，这是一种常用的方法。运维的同学不仅需要上线产品、还需要下线产品、灰度发布，还需要24h检测服务器的运行。在业务扩展的时候，需要及时部署、添加新的服务器。当出现问题时，他们需要将当前服务器上的业务transfer到其他机器上面，用户一般是不会感受到这种变化的。
12、爬行、搜索服务器
像一些短视频公司，除了自己生产内容之外，另外一个很重要的工作就是对全网进行爬行工作。等到内容获取之后，就会用数据库固化下来，这个时候就需要搜索服务器的帮助了。关于搜索这方面，现在有一些开源的软件可以供使用，比如solr。
13、推荐服务器
除了用户自己想搜索的内容外，系统一般也会推荐一些相关的内容。很多同学都会使用头条或者抖音，那么里面推荐服务器就要承担很重要的一部分工作。推荐服务器可以做得很简单、也可以做得很复杂，这个时候就看它是不是公司的主营业务了。当然不光是头条这些公司很在意推荐，像一些电子商务网站也是很在意推荐服务，因为它会增加公司的销售额，在很大程度上提升企业的效益。
14、待机服务器
服务器也不是一直都能稳定工作的，这个时候准备一些待机服务器还是很有必要的。
上面谈了这么多，大家会发现，现在企业级的网站后端其实已经很复杂了。业务量的激增、用户的需求，导致整个软件的架构一直在改变。好的软件架构不光可以满足当前的业务需要，而且为未来的扩展打下基础。至于jvm、jdk、mysql、mysql proxy、tomcat、Spring、TiDB、nginx、Keepalive、zookeeper、solr、fastDFS、docker、hadoop、vmware等软件，这些都是为架构服务的，等到真正用的时候学习一些就可以了。当然，使用的时候，可以用java、也可以不用java，这个可以根据自己的情况灵活安排。
另外，关于jvm & jdk可以多说一些，它就是一门编程语言而已，不要神化也不要贬低。和其他很多编程语言一样，比如lua，它也有lua & luac，其中lua负责运行虚拟机、垃圾回收等动作，而luac负责整个编程语言的编译。处理好java & javac，如果能多看看jdk源码，用javap调试一下反汇编代码，这样就更好了，对个人发展也大有裨益。
用java学习分布式，一方面是这方面项目使用的最多、经验最为丰富，另外一方面也是因为java语言本身使用的最为广泛、工具最多。大家可以根据自己的情况，一步一步去学习就可以了。从软件架构来说，java和分布式这个主题，可以给大家带来很多积极和有益的思考。
说到架构，或者软件框架，这个和os没有关系，和编译器、编程语言没有多大关系。只是有的时候，为了部署方便，选用一个平台、一个语言而已。分布式架构里面有成功、失败、超时三个情况，而超时就是最大的问题。所以，如何处理这个超时问题才是重中之重。当然，很多朋友都听过cap理论，也就是高可用性、性能、一致性，一般只能三者取其二。现实的情况是高可用性 > 性能 > 一致性，一个简单的例子就是很多时候我们在前台提交了数据，需要很久后台能才刷新出来。
当然，分布式调试也是一个问题。如果程序运行过程中遇到网络失败的问题。这个里面有可能是客户端的问题，也可能是调度服务器的问题，Web服务器的问题，消息服务器的问题，微服务的问题，缓存的问题，数据库的问题，分布式固然能满足效率和流量、存储的需求，但是也会带来其他需要解决的问题。
此外，大家要知道，高并发、高性能也需要客户端的配合。至少你不能让所有的客户端都连载在一个ip、一个port上，这个不合适吧？当然，客户端优化也是很重要的一个工作。
标签：获取 不同 uac 存储 检测服务 keepalive 导致 遇到 缺点
原文地址：https://www.cnblogs.com/wdsj9/p/14729095.html
