前篇文章从交易算法和交易社区的畅想中，提到一个话题：“均贫富，共天下。共产主义是个美好的愿景。”

这阵子接触，比特币和区块链。发现这才真正是“开放公平的生存环境。通过贡献值，按劳分配，这才是一种贡献力的挖金游戏啊~~~！！！”

“共产金融”、“共进金融”，在比特币这里还真的不是一个玩笑话了。而是真正有了技术落地的实际基础。

---

无法否认区块链仍处在一种新技术热潮的初级的躁动期，太多浮躁太多投机的噪音。所以很多时候我们接触这个事物，让人饱受一种山雨欲来的焦虑感。但是解法也很简单，我们只需要梳理一个思维框架来认识这一新事物，任各路妖魔布道者怎么蛊惑，照样也能够抓住“本质”的东西。

下面的思维导图是一种基础的认识框架，通过一段话说明就是：

###正确认识并承认，区块链不只是一阵新技术热潮，而是一种社会变革前的全球性思潮（新思想呼唤新规则的大潮）；我们再从三道演化路径来审视，事物演化进化中，是如何推生出现在的区块链和比特币；这三道演化路径，都是回归一个初衷，一个公平公正社会生产关系的初衷，进一步说，甚至是马克思等等社会思想家寻求的理想社会形态；既然这股新思潮会推动社会形态的进化，那么我们最后再来畅想一下，未来的社会形态应该有哪些想象力呢？

均贫富，共天下。共产主义是个美好的愿景。

从小就蛮喜欢赤色情怀的。当然严格意义地说不能叫赤色情怀，因为从古雅典柏拉图开始，伟大的先哲就已经热烈思考『理想国』的设计构建。

赤色情怀别具魅力，源于近代世界革命热潮，它既在理论层面点燃了一盏耀眼明灯，也在实际作用层面拯救了一大片国家和人民（包括中国）。

追求更精确的社会运转逻辑，追求更公平完美的社会形态，共产主义可是绝佳的思考范本。

人类社会的究竟归途，一种是宗教形而上地超然存在，二种就是理想的共产主义吧。

有人的地方就有人性，有人性的地方就有竞争。同样，宗教方位不同，神明也就不同，神明的理念间也会有差异。根本上，逃不开竞争和矛盾。

那是否可以存在，一种既尊重合理竞争法则，又能够共同进步生存的『共进模式』呢？

共进模式也并不是绝对的，比如在古代城邦打仗，A城邦打赢了B城邦，那么A给予B民众生存权，做A的奴隶，初期B民众还是感恩戴德的，只是这种原始野蛮的『共进模式』会快速消耗不同阶级的矛盾缓冲层，矛盾由此变得愈加尖锐，共进模式的意义也就消失了。

开篇标题也点名了重点，就是谈谈这阵子摸索的『社会化跟单金融交易』这新事物。从社会制度形态的层面说，这可是很有创新性、试验性的新兴社会形态呢。因为这种社群跟单交易模式，就是一种『共进模式』的社会基础规则设计。

有几个感性认识，越想越让人兴奋，激动这可是一个很好的社会形态范本，

• 开放公平的竞技环境。竞技的目的简单粗暴，就是一种智力挖金游戏。
• 社会达尔文主义地优胜劣汰。低级玩家是要被高级玩家收割的，而聪明的玩家可以规避风险，选择和认可的玩家站在一起。
• 同步联动宏观人类社会活动。进行货币交易，就是一种和整个人类活动的相互作用关系。意义实际。

当然，仔细深思这几点的时候，不得不承认。这个游戏是残酷的，大多数玩家本身就是先天理性缺失，好在这种社会化跟单金融交易，就是给了他们一种投票跟单上车的生存权。

我个人也同样是投票跟单上车来赢取生存权。

一年摸索货币交易下来，尝试用政治&经济学理解金融和金融交易的社会落脚点。

摸索出更实际的辅助工具，而落实点就是『临渊交易员测评』 。口号就是目的，也是简单粗暴，『挖掘有价值的交易员』。

用客观的数理统计评估交易历史的手段，实效主义地挖掘出那些有价值的、能赚钱的交易员。

在信息烦乱、发达、烦闷、冗杂的繁荣停滞社会，有一些痛苦而美好的竞技博弈会让社会更健康。

ps：这篇的标题用『共进金融』其实更贴切一些，不过『共产』意味着一种美好的期待和努力，也是挺好的。

GreatBook《大型网站技术架构》

在多年工作实践中，对前端、后端服务分层架构长期处在零碎的实践体会，即便身在云平台也极少有机会从整体视角来认识云平台的深层架构原理。网上零碎资料文章虽多，但缺少严谨地架构知识讲述，不足以作为专业认识的入口。所以当看到李智慧这本书《大型网站技术架构》时，让人非常激动，多年来处于朦胧不清的架构知识被智慧哥用通俗易懂的语言总结出来。

于是速速读来，慢慢体会，将书中个人认为的最为精要的“架构认知点”进行系统梳理总结。

A、服务器架构演化

架构的演化方向，如果归结为笼统原则，就是“缓存化”+“分布式化”。

书中将小网站演化到大型网站需要10步。这10步也可以理解为架构演化的标准路线，带着上面所说的笼统原则来看看这10步演化路线，也会更能体会进行的方向。

1. 初始阶段的网站架构：比如，单体应用，单体LAMP架构。在这个阶段，应用程序，数据库，文件等所有的资源都在一台服务器上。（对应下图1.1）
2. 分离“应用服务器”和“数据服务器”：这个时候，应用和数据分离后整个网站使用三台服务器，a应用服务器，b文件服务器和c数据库服务器。这也是第一步进行分离的架构操作，由此迈出架构进化路线。（对应下图1.2）
3. 使用缓存改善网站性能：网站使用的缓存可以分为两种：缓存在，应用服务器上的a本地缓存和缓存在专门的分布式缓存服务器上的b远程分布式缓存。（对应下图1.3）
4. 使用应用服务器集群改善网站的并发处理能力：每一种集群都是一种类型的应用服务器，进而能进行均衡负载且冗余容错支撑。使用集群也是网站解决高并发、海量数据问题的常用手段。（对应下图1.4）
5. 数据库读写分离：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。（对应下图1.5）
6. 使用反向代理和CDN加速网站响应：CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。（对应下图1.6）
7. 使用分布式文件系统和分布式数据库系统：分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。 （对应下图1.7）
8. 使用NoSQL和搜索引擎：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。网站需要采用一些非关系数据库技术NoSQL和非数据库查询技术如搜索引擎来进行满足。应用服务器通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。（对应下图1.8）
9. 业务拆分：大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段讲整个网站业务分成不同的产品线。应用之间则通过一个超链接建立关系，背后也可以通过消息队列进行数据的分发。（对应下图1.9）
10. 分布式服务：既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务。

如果能够有幸跟随某个产品某个网站一起成长到第10步，那会是非常难得的机遇和挑战。

架构的演化方向，归结为笼统原则，就是 “缓存化”+“分布式化”，这有助于理解上面的进化方向。当然这个说法还不够专业和理论化，所以就有了下一部分B中提到的 “服务器架构模式”。

B、服务器架构模式

关于什么是模式，这个来自建筑学的词汇是这样定义的：“每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作”。

模式的关键在于模式的可重复性，以及指出了事物本质的共性。

换一种说法，架构模式就是一种： “架构师进行架构工作的核心思维方式”。

用下面一张导图来概括这些架构模式。

再选取其中关键的要素进行阐述，比如，分层，分布式，缓存

• “架构的分层”：分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。分层结构在计算机世界中无处不在，网络的7层通信协议是一种分层结构；计算机硬件、操作系统、应用软件也可以看作是一种分层结构。
• 架构的分布式：对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。【分布式常有：1.分布式应用和服务；2.分布式静态资源；3.分布式数据和存储；4.分布式计算；】
• 架构的缓存：缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。使用缓存的例子：CDN，反向代理，本地缓存，分布式缓存。

架构模式，简单的理解，就可以认为主要是“分布式化”+“缓存化”再进行场景细化针对的实践。

C、服务器核心架构要素

一般来说，除了当前的系统功能需求外。软件架构还需要关注 性能、可用性、伸缩性、扩展性和安全性这5个架构要素。

C-1、性能

衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等。通过检测这些指标以确定系统设计是否达到目标。这些指标也是网站监控的重要参数，通过监控这些指标可以分析系统瓶颈，预测网站容量，并对异常指标进行报警，保障系统可用性。

改善性能的手段要素，可以借鉴上面10步进行路线中针对每一种阶段遇到的问题进行性能的针对性提升。

也就是泛指的 缓存化+分布式化。这也是实现 “高性能架构”的主要进化策略。

C-2、可用性

可用性，其实可以理解为全年全天360 * 24 * 7 hour的可用性，因为大型服务器架构任何时候都有用户的活跃性，所以就需要极高的无缝可用性。

网站高可用的主要手段是 集群化的冗余。应用部署在多台服务器上同时提供服务访问，数据存储在多台服务器上相互备份，任何一台服务器挂掉都不会影响整体服务的可用性。（在庞大的服务器集群中服务器意外宕机都是能够进行容错的，这就是高可用的基础）

集群化的冗余。这也就是实现“高可用架构”主要策略。

C-3、伸缩性

大型网站面对海量用户的高并发访问和数据IO，随着架构升级，演化为通过集群的方式将多台服务器编排组成一个整体的服务集群来共同提供服务。

而所谓的伸缩性就是指，通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

实践高伸缩性的主要策略就是，设计一种友好便携的集群机器的增减策略。

C-4、扩展性

衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明且无影响，不需要改动或者很少改动既有业务功能就可以上线新产品。不同产品模块之间可以极少相互牵制的耦合关系。

网站伸缩架构的主要手段是 事件驱动架构和分布式服务。

• 事件驱动架构，就是设计一个消息队列MQ，将用户请求or其他业务事件构造成消息防止到消息队列，消息队列MQ再去集群中寻找消息处理者。这就将消息产生，消息处理分离开，可以在遇到吞吐量不足时灵活在集群中增加消息处理应用。

• 分布式服务，则是上面提到的几种分布式手段。

C-5、安全性

架构安全性是个大话题，由于业务生产需求和产品经理的节奏一定快于安全措施的跟踪实施，所以在进行架构扩张时，最容易出现重大安全隐患，所以这需要在快速业务和安全性间保持平衡。也需要在产品稳定后进行查缺补漏相应的安全措施。