引见
这一系列文章, 旨在形貌面对一个从零开始的 B(C)/S 运用的时刻, 怎样去搭建一个营业无关的平台, 承载上层运用流量. 这里要强调这个平台的几个特性:
- 营业无关性: 不管营业的形状怎样, 均能够在此架构之上运转, 这里可能会面对多少状况, 如无状况效劳, 长衔接效劳等, 后续会依据场景运转形貌, 然则这些场景能够看做是一个有限集.
- 可扩大性: 这里的扩大性特指两个方面, 一是营业的扩大, 二是流量的增添, 这两者关于任何一个平台而言, 都是要偏重斟酌的.
营业依据差别的目标, 能够分为多少类, 这里希冀经由过程两种目标来形貌这一系列文章想要掩盖的场景, 以申明营业无关性:
- 依据状况: 分为
无状况效劳和有状况效劳 - 依据及时性: 分为
异步与及时运用
这两个目标能够恣意组合, 然则最经常使用的组合应该是属于无状况-异步及有状况-及时运用了, 然则一般也会有无状况-及时运用存在, 比方关于一个博客体系, 能够以为其是一个无状况-异步运用, 而一个一对一的谈天运用, 则能够看做是无状况-及时运用, 而大多数在线游戏, 则是有状况-及时运用, 须要注重的是, 营业场景不会严厉根据上述观点举行辨别, 终究大多都邑构成一个无状况与有状况, 异步与及时共存的状况.
微效劳化是满足扩大性的基石, 这也是文章会起首形貌的一个整体性架构, 单机运用会在后期激发多少难以解决的题目, 所以这是一开始就须要斟酌到的事变.
文章会重要形貌以下几个部份:
- 运用分支与模块化
- 延续集成
- 有状况的长衔接运用扩大性设想
- Web 端构建与模块化
微效劳的存在, 以致运用疏散在多少效劳器集群中, 怎样有用治理集群是一个比较巨大的话题, 然则现在业界已经有了比较一致的具有完整性的手艺计划, 如k8s, rancher等, 特别是云效劳商的涌现, 掩盖了硬件治理这个最庞杂的环节, 所以这里不会去议论关于容器编排相干的话题.
