我们永远无法构建一个高并发系统

文字游戏

以题引题，“ 我们永远无法构建一个高并发系统 ”，因为这是一个伪命题。高并发并不适合用来描述一个系统的特点，它只是说的这个系统适用的场景是高并发环境。高并发指的是我们的系统可以同时并发的处理多个任务请求，在这种场景下，依然能保持系统稳定高效。这绝不是一个文字游戏，做任何事情之前我们首先应该搞清楚一件事情的概念定义，让各个角色各司其职，这样我们才能找准方向正确的推动一件事情的发展，架构甚是如此。

架构是什么

描述一个架构的特点应该是从可伸缩、高可用、高性能等几个方面出发，从这些特点去衡量一个架构的好坏。一个架构要看这个架构可伸缩性强不强，是否能在紧急情况下快速扩容。比如我们我们一个商城网站，在国庆春节的时候用户流量会成几倍的增长，这时候原有的架构规模可能无法支撑如此规模的业务处理，我们的架构应该具有可快速扩容的能力，在短时间内达到满足场景的架构扩张，而在活动结束后为了节省服务器资源，这一切应该在用户无感知的情况下悄悄的恢复，当然在有了容器化之后这些都变的不在复杂。再有一个特点我们会经常拿TPS、QPS去衡量一个系统的吞吐性能，这些指标可以表示一个系统的性能高低，同样是我们常用来衡量性能好坏的标准。但是一个系统单从某一点都无法说明其架构的好坏与否，需要综合各方面的因素评定，没有最好的架构只有最合适的架构，架构合适了，一切才能正常的发展。

如何做合适的架构

适应当前组织结构的真实情况，能够恰好满足当前体系要求的架构才是合适的架构。大部分人认为我们需要为未来做长久规划，这自然正确，但是往往绝大部分情况我们都无法预测未来的发展。社会在变化，组织在变化，那自然应该允许我们的架构也发生变化以适应所需。这两种方向并不是两个极端，任何事情之间都需要一个权衡取舍，我们所说的trade-off。

阿里架构发展

阿里最初也是从最简的LAMP架构起家，2003年靠从买来的一套系统部署在几台简单的服务器上做起了业务，这套架构是适合他们当时情况的最合适的架构，因为那时没有知道以后的世界怎么样。

04年开始，疯狂的数据增长，发现这一套架构在难以满足现有的需求，阿里尝试过把mysql更换为Oracle，后又将开发语言换位java等等，因为当时的技术瓶颈受限于sun，这对此时也是最合适的架构了。再到后来阿里自研了各种技术与中间件，经历集群负载、SOA 到分布式微服务逐渐到今天构建起强大的技术帝国，在技术领域内占据着举足轻重的位置。为什么他们不一开始直接上来微服务分布式？当时的技术大环境也没有这些东西啊，阿里已经几乎可以代表当时技术的顶尖水平了。

维基百科

与之形成对比的由我们熟悉的维基百科，它是全球第六大最受欢迎网站，靠一个非营利的基金会来运营，整个技术团队十几个人组成，并且完全自发。维基百科技术架构相比于阿里并没有如此庞大的遍布全球的集群服务器支撑，技术规模也远远不足，但是依然占据着举足轻重的地位。

如上便是维基百科的规模与使用的技术，其中的技术大部分我们都有所熟知，但是就是这些看不起眼的组件服务支撑着全球的流量。并不是最先进、最庞大的的技术群就一定构建起最好的架构，而最适合的架构才称得上是最好的架构。

真正的架构

生活中的一切都需要架构，并不仅仅是技术。有了合适的大体的框架，才能顺着整体架构健康发展。例如一个公司的组织架构，如果没有合适的规划，人员组织混乱，势必难以发展壮大。优秀的架构才能吸引来优秀的员工，而优秀的员工加优秀的架构才能创建出优秀的企业。

最后

总要有最后，说到了最后才发现这个文章架构规划的不是太好。我想表达的事情很多，什么是架构、架构的发展史，又想拿比如阿里，维基百科等等去举例子谈一下他们架构的演变与发展，后面又去谈了公司的人员组织架构和我们的生活架构，规划了很多很大。可是我根本没有这么足够的时间去说，或是我根本没有准备的那么充分，因为这里每一个的细节说起来都可以成为一个长篇小说了，显然我这样的架构思路规划就是不友好的，并不是一个好的架构规划。所有的一切通过一个不着边际的题目，其实主要说只有最合适的架构才是最好的架构。