原文地址&＃xff1a;http://www.cnblogs.com/virusswb/archive/2012/01/10/2318169.html
文章写的很好&＃xff0c;转载一些到自己的博客上留作以后的学习目标
Javascript&＃xff1a;Jquery&＃xff0c;prototype.js&＃xff0c;Kissky&＃xff0c;extjs。
.NET&＃xff1a;企业库&＃xff0c;unity&＃xff0c;NHibernate&＃xff0c;Sprint.NET&＃xff0c;ibatis&＃xff0c;MVC&＃xff0c;MEF&＃xff0c;Prism&＃xff0c;log4net&＃xff0c;23个开源项目&＃xff0c;lucene.NET
Java&＃xff1a;hibernate&＃xff0c;spring&＃xff0c;struts&＃xff0c;easyjf&＃xff0c;log4j&＃xff0c;开源项目&＃xff0c;lucene
Python&＃xff1a;django&＃xff0c;flask&＃xff0c;bottle&＃xff0c;tornado&＃xff0c;uliweb&＃xff0c;web.py
Ruby&＃xff1a;rails
PHP&＃xff1a;PEAR
2.3缓存
•Squid cache
开源。
Squid服务器群&＃xff0c;把它作为web服务器端的前置cache服务器&＃xff0c;缓存相关请求来提高web服务器速度。Squid将大部分静态资源(图片&＃xff0c;js&＃xff0c;css等&＃xff09;缓存起来&＃xff0c;也可以缓存频繁访问的网页&＃xff0c;直接返回给访问者&＃xff0c;减少应用服务器的负载。
•memcached
开源。
Wikipedia&＃xff0c;Flickr&＃xff0c;Twitter&＃xff0c;Youtube
memcached服务器群&＃xff0c;一款分布式缓存产品&＃xff0c;很多大型网站在应用; 它可以应对任意多个连接&＃xff0c;使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间&＃xff0c;然后建立一个HashTable&＃xff0c;Memcached自管理这些HashTable。因为通常网站应用程序中最耗费时间的任务是数据在数据库的检索&＃xff0c;而多个用户查询相同的SQL时&＃xff0c;数据库压力会增大&＃xff0c;而通过memcached的查询缓存命中&＃xff0c;数据直接从memcached内存中取&＃xff0c;每次缓存命中将替换到数据库服务器的一次往返&＃xff0c;到达数据库服务器的请求更少&＃xff0c;间接地提高了数据库服务器的性能&＃xff0c;从而使应用程序运行得更快。它通过基于内存缓存对象来减少数据库查询的方式改善网站系统的反应&＃xff0c;其最吸引人的一个特性就是支持分布式部署。
2.4中间件
Java&＃xff0c;.net&＃xff0c;c&＃xff0c;c&＃43;&＃43;
2.5存储
2.5.1关系数据库
Oracle&＃xff0c;mysql&＃xff0c;mssql&＃xff0c;postgreSQL
postgreSQL
关系数据库&＃xff0c;拥有15年的历史。免费&＃xff0c;开源。可以运行在linux、unix和windows上&＃xff0c;支持事物、主外键、连接、视图、触发器、存储过程。包含大量的数据类型&＃xff0c;也支持大对象。支持多种语言&＃xff0c;c&＃xff0c;c&＃43;&＃43;&＃xff0c;java&＃xff0c;c#&＃xff0c;perl&＃xff0c;python&＃xff0c;ruby等等。
2.5.2 NoSQL存储
MongoDB&＃xff0c;Redis&＃xff0c;CouchDB&＃xff0c;Cassandra&＃xff0c;HBase
NoSQL(not only sql)&＃xff0c;不仅仅是SQL。用来弥补关系数据库在某些方面的不足。例如&＃xff1a;
l 高并发读写。每秒上万次的读写&＃xff0c;关系数据库有点吃力。
l 海量数据的高效存储和访问。例如&＃xff1a;对一张表有2亿数据的表进行读写&＃xff0c;效率较为低下。
l 高扩展性。对于数据库的升级和扩展&＃xff0c;增加节点&＃xff0c;往往需要停机和数据迁移。
有一些地方不需要关系数据库&＃xff0c;例如&＃xff1a;
l 事务一致性。某些场合不需要事务&＃xff0c;对于数据的一致性也没有严格要求。
l 读写实时性。有些场合不需要实时的读写。
http://baike.baidu.com/view/2677528.htm
Mongodb
文档型nosql&＃xff0c;支持主从复制。有很多的大公司使用。支持多种编程语言。
http://www.mongodb.org/display/DOCS/Production&＃43;Deployments
Disney&＃xff0c;SAP&＃xff0c;淘宝&＃xff08;监控数据&＃xff09;&＃xff0c;sourceforge&＃xff0c;大众点评&＃xff08;用户行为分析&＃xff0c;用户、组&＃xff09;。
Redis
键值型nosql&＃xff0c;vmware赞助&＃xff0c;支持多种编程语言。Twitter&＃xff0c;淘宝&＃xff0c;新浪微博都有使用。
Couchdb&＃xff0c;cassandra&＃xff0c;hbase
都是apache旗下的项目。
2.5.3文件系统
商用中间件&＃xff0c;自定义文件系统
2.6操作系统
Windows&＃xff0c;linux&＃xff0c;unix
2.7 Web应用服务器软件
IIS&＃xff0c;apache&＃xff0c;tomcat&＃xff0c;jboss&＃xff0c;weblogic&＃xff08;BEA&＃xff0c;商用&＃xff0c;收费&＃xff09;&＃xff0c;websphere&＃xff08;IBM&＃xff0c;商用&＃xff0c;收费&＃xff09;&＃xff0c;lighttpd&＃xff0c;nginx
IIS
微软windows操作系统专用。
Lighttpd
lighttpd&＃xff0c;是一个德国人领导的开源软件&＃xff0c;其根本的目的是提供一个专门针对高性能网站&＃xff0c;安全、快速、兼容性好。lighttpd并且灵活的web server环境。具有非常低的内存开销&＃xff0c;cpu占用率低&＃xff0c;效能好&＃xff0c;以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能&＃xff0c;
Nginx
开源
Nginx&＃43;php&＃xff08;FastCGI&＃xff09;&＃43;Memcached&＃43;Mysql&＃43;APC 是目前主流的高性能服务器搭建方式&＃xff01;适合大中型网站&＃xff0c;小型站长也可以采用这种组合&＃xff01;
Nginx 超越 Apache 的高性能和稳定性&＃xff0c;使得国内使用 Nginx 作为 Web 服务器的网站也越来越多&＃xff0c;其中包括国内最大的电子地图MapBar、新浪博客、新浪播客、网易新闻等门户网站频道&＃xff0c;六间房、56.com等视频分享网 站&＃xff0c;Discuz&＃xff01;官方论坛、水木社区等知名论坛&＃xff0c;豆瓣、YUPOO相册、海内SNS、迅雷在线等新兴Web 2.0网站&＃xff0c;更多的网站都在使用Nginx配置。
2.8 框架
Javascript&＃xff1a;Jquery&＃xff0c;prototype.js&＃xff0c;Kissky&＃xff0c;extjs。
.NET&＃xff1a;企业库&＃xff0c;unity&＃xff0c;NHibernate&＃xff0c;Sprint.NET&＃xff0c;ibatis&＃xff0c;MVC&＃xff0c;MEF&＃xff0c;Prism&＃xff0c;log4net&＃xff0c;23个开源项目&＃xff0c;lucene.NET
Java&＃xff1a;hibernate&＃xff0c;spring&＃xff0c;struts&＃xff0c;easyjf&＃xff0c;log4j&＃xff0c;开源项目&＃xff0c;lucene
Python&＃xff1a;django&＃xff0c;flask&＃xff0c;bottle&＃xff0c;tornado&＃xff0c;uliweb&＃xff0c;web.py
Ruby&＃xff1a;rails
PHP&＃xff1a;PEAR
3.主流网站架构演进
3.1第一步&＃xff1a;物理分离webserver和数据库
刚开始我们的网站可能搭建在一台服务器上&＃xff0c;这个时候由于网站具备了一定的特色&＃xff0c;吸引了部分人访问&＃xff0c;逐渐你发现系统的压力越来越高&＃xff0c;响应速度越来越慢&＃xff0c;而这个时候比较明显的是数据库和应用互相影响&＃xff0c;应用出问题了&＃xff0c;数据库也很容易出现问题&＃xff0c;而数据库出问题的时候&＃xff0c;应用也容易出问题&＃xff0c;于是进入了第一步演变阶段&＃xff1a;将应用和数据库从物理上分离&＃xff0c;变成了两台机器&＃xff0c;这个时候技术上没有什么新的要求&＃xff0c;但你发现确实起到效果了&＃xff0c;系统又恢复到以前的响应速度了&＃xff0c;并且支撑住了更高的流量&＃xff0c;并且不会因为数据库和应用形成互相的影响。
图3.1
3.2第二步&＃xff1a;增加页面缓存
好景不长&＃xff0c;随着访问的人越来越多&＃xff0c;你发现响应速度又开始变慢了&＃xff0c;查找原因&＃xff0c;发现是访问数据库的操作太多&＃xff0c;导致数据连接竞争激烈&＃xff0c;所以响应变慢&＃xff0c;但数据库连接又不能开太多&＃xff0c;否则数据库机器压力会很高&＃xff0c;因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力&＃xff0c;这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面&＃xff08;例如一两天才会有更新的页面&＃xff09;进行缓存&＃xff08;当然&＃xff0c;也可以采用将页面静态化的方案&＃xff09;&＃xff0c;这样程序上可以不做修改&＃xff0c;就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争&＃xff0c;OK&＃xff0c;于是开始采用squid来做相对静态的页面的缓存。
图3.2
3.3第三步&＃xff1a;增加页面片段缓存
增加了squid做缓存后&＃xff0c;整体系统的速度确实是提升了&＃xff0c;webserver的压力也开始下降了&＃xff0c;但随着访问量的增加&＃xff0c;发现系统又开始变的有些慢了&＃xff0c;在尝到了squid之类的动态缓存带来的好处后&＃xff0c;开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢&＃xff0c;因此考虑采用类似ESI之类的页面片段缓存策略&＃xff0c;OK&＃xff0c;于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
图3.3
3.4第四步&＃xff1a;数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后&＃xff0c;系统的压力确实进一步降低了&＃xff0c;但同样&＃xff0c;随着访问量的增加&＃xff0c;系统还是开始变慢&＃xff0c;经过查找&＃xff0c;可能会发现系统中存在一些重复获取数据信息的地方&＃xff0c;像获取用户信息等&＃xff0c;这个时候开始考虑是不是可以将这些数据信息也缓存起来呢&＃xff0c;于是将这些数据缓存到本地内存&＃xff0c;改变完毕后&＃xff0c;完全符合预期&＃xff0c;系统的响应速度又恢复了&＃xff0c;数据库的压力也再度降低了不少。可以使用的技术有&＃xff1a;memcached。
图3.4
3.5第五步&＃xff1a;增加webserver
好景不长&＃xff0c;发现随着系统访问量的再度增加&＃xff0c;webserver机器的压力在高峰期会上升到比较高&＃xff0c;这个时候开始考虑增加一台webserver&＃xff0c;这也是为了同时解决可用性的问题&＃xff0c;避免单台的webserver down机的话就没法使用了&＃xff0c;在做了这些考虑后&＃xff0c;决定增加一台webserver&＃xff0c;增加一台webserver时&＃xff0c;会碰到一些问题&＃xff0c;典型的有&＃xff1a;
1、如何让访问分配到这两台机器上&＃xff0c;这个时候通常会考虑的方案是Apache自带的负载均衡方案&＃xff0c;或LVS这类的软件负载均衡方案&＃xff1b;
2、如何保持状态信息的同步&＃xff0c;例如用户session等&＃xff0c;这个时候会考虑的方案有写入数据库、写入存储、COOKIE或同步session信息等机制等&＃xff1b;
3、如何保持数据缓存信息的同步&＃xff0c;例如之前缓存的用户数据等&＃xff0c;这个时候通常会考虑的机制有缓存同步或分布式缓存&＃xff1b;
4、如何让上传文件这些类似的功能继续正常&＃xff0c;这个时候通常会考虑的机制是使用共享文件系统或存储等&＃xff1b;
在解决了这些问题后&＃xff0c;终于是把webserver增加为了两台&＃xff0c;系统终于是又恢复到了以往的速度。
图3.5
3.6第六步&＃xff1a;分库
享受了一段时间的系统访问量高速增长的幸福后&＃xff0c;发现系统又开始变慢了&＃xff0c;这次又是什么状况呢&＃xff0c;经过查找&＃xff0c;发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈&＃xff0c;导致了系统变慢&＃xff0c;这下怎么办呢&＃xff0c;此时可选的方案有数据库集群和分库策略&＃xff0c;集群方面像有些数据库支持的并不是很好&＃xff0c;因此分库会成为比较普遍的策略&＃xff0c;分库也就意味着要对原有程序进行修改&＃xff0c;一通修改实现分库后&＃xff0c;不错&＃xff0c;目标达到了&＃xff0c;系统恢复甚至速度比以前还快了。
图3.6
3.7第七步&＃xff1a;分表、DAL和分布式缓存
随着系统的不断运行&＃xff0c;数据量开始大幅度增长&＃xff0c;这个时候发现分库后查询仍然会有些慢&＃xff0c;于是按照分库的思想开始做分表的工作&＃xff0c;当然&＃xff0c;这不可避免的会需要对程序进行一些修改&＃xff0c;也许在这个时候就会发现应用自己要关心分库分表的规则等&＃xff0c;还是有些复杂的&＃xff0c;于是萌生能否增加一个通用的框架来实现分库分表的数据访问&＃xff0c;这个在ebay的架构中对应的就是DAL&＃xff0c;这个演变的过程相对而言需要花费较长的时间&＃xff0c;当然&＃xff0c;也有可能这个通用的框架会等到分表做完后才开始做&＃xff0c;同时&＃xff0c;在这个阶段可能会发现之前的缓存同步方案出现问题&＃xff0c;因为数据量太大&＃xff0c;导致现在不太可能将缓存存在本地&＃xff0c;然后同步的方式&＃xff0c;需要采用分布式缓存方案了&＃xff0c;于是&＃xff0c;又是一通考察和折磨&＃xff0c;终于是将大量的数据缓存转移到分布式缓存上了。
图3.7
3.8第八步&＃xff1a;增加更多的webserver
在做完分库分表这些工作后&＃xff0c;数据库上的压力已经降到比较低了&＃xff0c;又开始过着每天看着访问量暴增的幸福生活了&＃xff0c;突然有一天&＃xff0c;发现系统的访问又开始有变慢的趋势了&＃xff0c;这个时候首先查看数据库&＃xff0c;压力一切正常&＃xff0c;之后查看webserver&＃xff0c;发现apache阻塞了很多的请求&＃xff0c;而应用服务器对每个请求也是比较快的&＃xff0c;看来是请求数太高导致需要排队等待&＃xff0c;响应速度变慢&＃xff0c;这还好办&＃xff0c;一般来说&＃xff0c;这个时候也会有些钱了&＃xff0c;于是添加一些webserver服务器&＃xff0c;在这个添加webserver服务器的过程&＃xff0c;有可能会出现几种挑战&＃xff1a;
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量&＃xff08;请求连接数、网络流量等&＃xff09;的调度了&＃xff0c;这个时候如果经费允许的话&＃xff0c;会采取的方案是购买硬件负载&＃xff0c;例如F5、Netsclar、Athelon之类的&＃xff0c;如经费不允许的话&＃xff0c;会采取的方案是将应用从逻辑上做一定的分类&＃xff0c;然后分散到不同的软负载集群中&＃xff1b;
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈&＃xff0c;需要进行改进&＃xff0c;也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等&＃xff1b;
在做完这些工作后&＃xff0c;开始进入一个看似完美的无限伸缩的时代&＃xff0c;当网站流量增加时&＃xff0c;应对的解决方案就是不断的添加webserver。
图3.8
3.9第九步&＃xff1a;数据读写分离和廉价存储方案
突然有一天&＃xff0c;发现这个完美的时代也要结束了&＃xff0c;数据库的噩梦又一次出现在眼前了&＃xff0c;由于添加的webserver太多了&＃xff0c;导致数据库连接的资源还是不够用&＃xff0c;而这个时候又已经分库分表了&＃xff0c;开始分析数据库的压力状况&＃xff0c;可能会发现数据库的读写比很高&＃xff0c;这个时候通常会想到数据读写分离的方案&＃xff0c;当然&＃xff0c;这个方案要实现并不容易&＃xff0c;另外&＃xff0c;可能会发现一些数据存储在数据库上有些浪费&＃xff0c;或者说过于占用数据库资源&＃xff0c;因此在这个阶段可能会形成的架构演变是实现数据读写分离&＃xff0c;同时编写一些更为廉价的存储方案&＃xff0c;例如BigTable这种。
图3.9
3.10第十步&＃xff1a;进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程&＃xff0c;终于是再度迎来了完美的时代&＃xff0c;不断的增加webserver就可以支撑越来越高的访问量了&＃xff0c;对于大型网站而言&＃xff0c;人气的重要毋庸置疑&＃xff0c;随着人气的越来越高&＃xff0c;各种各样的功能需求也开始爆发性的增长&＃xff0c;这个时候突然发现&＃xff0c;原来部署在webserver上的那个web应用已经非常庞大了&＃xff0c;当多个团队都开始对其进行改动时&＃xff0c;可真是相当的不方便&＃xff0c;复用性也相当糟糕&＃xff0c;基本是每个团队都做了或多或少重复的事情&＃xff0c;而且部署和维护也是相当的麻烦&＃xff0c;因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间&＃xff0c;出问题的时候也不是很好查&＃xff0c;另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用&＃xff0c;还有其他的像调优不好操作&＃xff08;因为机器上部署的应用什么都要做&＃xff0c;根本就无法进行针对性的调优&＃xff09;等因素&＃xff0c;根据这样的分析&＃xff0c;开始痛下决心&＃xff0c;将系统根据职责进行拆分&＃xff0c;于是一个大型的分布式应用就诞生了&＃xff0c;通常&＃xff0c;这个步骤需要耗费相当长的时间&＃xff0c;因为会碰到很多的挑战&＃xff1a;
1、拆成分布式后需要提供一个高性能、稳定的通信框架&＃xff0c;并且需要支持多种不同的通信和远程调用方式&＃xff1b;
2、将一个庞大的应用拆分需要耗费很长的时间&＃xff0c;需要进行业务的整理和系统依赖关系的控制等&＃xff1b;
3、如何运维&＃xff08;依赖管理、运行状况管理、错误追踪、调优、监控和报警等&＃xff09;好这个庞大的分布式应用。
经过这一步&＃xff0c;差不多系统的架构进入相对稳定的阶段&＃xff0c;同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量&＃xff0c;结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。
图3.10
4.分析
随着平台做大做强&＃xff0c;很可能会走向定制操作系统&＃xff0c;定制数据库&＃xff0c;甚至定制硬件&＃xff0c;定制任何可以定制的东西这样一条路。
在服务器、架构、组件等技术选择方面&＃xff0c;主要有两个方向&＃xff1a;1选择成熟商用。2选择开源&＃43;自主研发。下面就这两个方向逐一进行简单分析。
1商用的优缺点
l 商用的优点之一是成熟&＃xff0c;稳定&＃xff0c;搭建快速。
l 商用的缺点之一是费用高&＃xff0c;随着服务器的增加&＃xff0c;license的费用上升&＃xff0c;成本偏高。
l 商用的产品是通用化的&＃xff0c;缺乏定制性&＃xff0c;不能满足个性需要。
2开源&＃43;自主研发的优缺点
l 源码开放&＃xff0c;可控性好&＃xff0c;出现问题&＃xff0c;可以从底层解决&＃xff0c;扩展性好。
l 短期时间、人力投入大&＃xff0c;初期见效慢&＃xff1b;长期产出大&＃xff0c;见效明显。
l 可以在软件和硬件的多个层面不断优化&＃xff0c;充分满足个性化需要。
商用和开源&＃43;自主研发各有优缺点&＃xff0c;各有互补性&＃xff0c;要根据使用场景的不同来进行选择&＃xff0c;也可以根据需要配合使用。
5.总结
目前大型网站的主流是LAMP&＃xff08;linux&＃43;apache&＃43;mysql&＃43;php&＃xff09;&＃xff0c;或者是在这基础之上的扩展&＃xff0c;例如增加缓存&＃xff0c;增加中间件&＃xff08;中间件大多使用java&＃xff0c;c&＃xff0c;c&＃43;&＃43;或者.NET编写&＃xff0c;或者购买成熟的中间件产品&＃xff0c;IBM就有很多成熟的中间件产品&＃xff09;&＃xff1b;又或者替换其中的某些部分&＃xff0c;例如前端使用python&＃xff0c;ruby&＃xff0c;lua这些新近流行的脚本语言&＃xff0c;数据存储部分使用nosql或者文件系统。这样的选择有历史原因、费用原因、业务原因&＃xff0c;也有在网站发展之后需要满足新的需求而衍生出来解决特定问题的原因。
也有初期使用微软系&＃xff08;windows&＃43;.NET&＃43;MSSQL&＃xff09;来构建网站的&＃xff0c;在后面又根据需要加入其他体系的的电商&＃xff0c;例如&＃xff1a;京东&＃xff0c;当当&＃xff0c;凡客等。也有始终采用微软系的网站&＃xff0c;国外的微软官网&＃xff0c;stackoverflow&＃xff0c;还有曾经辉煌的myspace。
其实&＃xff0c;现在的发展趋势是&＃xff1a;混合体系&＃xff0c;而非单一的体系。就是说技术体系不是单一的&＃xff0c;也不是固定一成不变的&＃xff0c;而是根据业务以及网站的发展&＃xff0c;以及技术的发展&＃xff0c;选择合适的技术解决适当的问题。
架构的变更不是一件小事&＃xff0c;对业务和网站的发展都很重要&＃xff0c;不可能几天或者一半个月就变更一下&＃xff0c;也不可能有事没事变更一下&＃xff0c;应该是在关键的时候&＃xff0c;有需要的时候&＃xff0c;或者根据计划定期升级。
我觉得有一种方式可以帮助我们进行选择。就是根据我们的目标&＃xff0c;或者说预估的业务量&＃xff0c;预估的成交量&＃xff0c;预估的用户量&＃xff0c;划分几个平台发展里程碑&＃xff0c;或者是时间段。然后根据平台发展的里程碑来规划技术选型的里程碑。考虑规模的同时&＃xff0c;还需要考虑业务的类型&＃xff0c;产生的数据的类型&＃xff0c;对这些数据的处理需求等因素。
可以先定几个里程碑&＃xff0c;这个里程碑的时间&＃xff0c;可以根据前面的业务预估来裁定。先根据第一个里程碑要满足的业务需求&＃xff0c;来选择当前的技术架构&＃xff0c;并且进行存储空间规划。然后针对第一个到第二个里程碑的过度&＃xff0c;进行预留设计&＃xff0c;保证将来的平稳过渡。或者只是预留扩展的余地&＃xff0c;这方面有时候有点难度&＃xff0c;不过应该尽量做。
在第二个里程碑之前的1-2个月进行第二个里程碑技术架构的讨论和设计&＃xff0c;因为这时候相比原有的第二个里程碑的业务估计可能会有变动&＃xff0c;或者技术上有了新的选择&＃xff0c;都可以及时考虑到本次的设计中来。以此类推后面的里程碑技术架构变更。
还有就是突发情况&＃xff0c;因为总会有一些意料之外的情况发生&＃xff0c;有的是业务发展的需要&＃xff0c;有的是被动的需要。针对这些突发情况&＃xff0c;也会进行架构的升级。
京公网安备 11010802041100号