1：本源



业务场景（市场）推动产品的演化，产品技术架构为解决产品问题而变。

业务特征（市场）--->业务问题（需求-主要非功能需求）---->架构演变（实现）

依赖关系：业务（心）-问题（相）-技术（饰）

心生相，饰修相

演变思维：问题技术都是按需演变的，不同阶段遇到不同问题，采用适合本阶段的解决方案。

互联网产品架构是跟随业务发展中伴随的问题逐步演变的。

1.1互联网产品面向C端用户-心

互联网产品核心特质是在在公共网络环境上面向不特定的C 端的大众用户，由用户驱动产品发展。

1：用户-不特定，越多越好

不特定的人，起初可能是想面对一类人，后续发展希望覆盖面越大越好，用户越多越好。

2：功能需求-用户驱动不断调整

先以某个特定场景需求为探索的起点，快速推向市场，在使用用根据市场反馈不断快速的调整，寻找定位，市场验证后再完善功能，成长后又会去寻找更多的场景满足更多人。



综上：用户使用驱动产品演变，成长后面对大量公众用户，公共网络环境为互联网产品 的主要业务特点。

互联网产品架构中面对的各种问题也多由核心特点决定。



1.2互联网产品面临的问题-相



功能需求不同产品面对场景不同，非功能需求互联网产品间基本都面临类似的问题。主要包括以下问题。

1：需求快速迭代，频繁发布新版本-扩展性

互联网产品终身都伴随的问题，起步阶段更明显。

2：用户范围广，网络环境复杂-可用易用

用户范围广：一般都要求使用简单，体验好，网络可用性要求也高 。

3：安全问题突出-安全性

面对的所有人不受限，且在互联网环境。可能有来自各个方面的攻击，信息泄漏等安全风险。

4：高可用性

用户需24小时使用

5：快速发展-成长的烦恼--扩展，弹性伸缩

使用量可能会快速增长，包括访问量，用户，数据等。

     对企业是好事，对技术也是挑战，如果观察到占了风口要做好快速增长压力的适应方案

6：高并发，海量数据

      高速成长后型互联网产品要面对的问题

7：检测用户行为---监控推荐

面向C端需要由用户使用反推系统进化，调整商业策略

（通用功能性要求-也可算非功能要求）



1.3互联网产品架构特质-饰



很多通用问题都有相应的应对方案，应对方案可能是某一个方面，也可能是从计算，数据，运维，团队，网络多个层方面考虑。而一个成熟的解决方案可能对多个问题都有帮助，或者是几个问题的综合应对。但同时方案本身也可能带来新的问题，也要有相应方案去应对上一个方案引入的问题。

遇到问题-寻求解决方案->实现技术支撑方案。问题与方案及技术间不是一对多而是多对多。即一个方案可能解决了多个问题，一个技术也能在多个方案中使用。

总体上从高性能，高可用，弹性伸缩，易扩展，高安全性是互联网产品架构主要特性。

下图是问题-方案-技术思路总结的，是树状的，但实际关系更像网。















2：成长



2.1业务成长-复杂与成熟

从初入世间时的纯真，进而曲折中探索，幸而快速成长，终于成熟壮大，这是成功互联网产品的大多成长轨迹。

总体的演变方向是越来越复杂，功能越来越多，越来越复杂，用户越来越多，数据量越来越多。三者相互推动，同时面对的安全边界也越大。



2.2 架构成长-拆分与完善



产品成长中伴随功能，用户，数据增加，会越来越复杂，解决复杂问题的思路就是分解，将复杂问题拆为更多的简单问题，更多的解决步骤，更多的资源（机器），拆给更合适的对象去解决。产品架构演变的主要路径就是拆,拆哪（下一步）->拆呢（正）->拆了（干完了）->拆哪（下一步）->......



2.2.1拆分中成长

1：应用数据分离

     解决单台硬件压力过大问题。

     将应用程序与数据库，文件服务拆分到不同的服务器。不同服务器根据特点采用升级硬件。

程序部署机器拆分

2：多级缓存

      解决高并发读压力。

     存储的性能赶不上计算速度，采用内存缓存减少多数据库的压力。

     包括分布式缓存，应用程序内部缓存。

读拆分为多个分离的阶段。硬盘-分布式内存缓存-计算程序内缓存。

3: 应用服务器集群

负载均衡+应用服务器集群解决高并发计算压力。

拆分为多个机器分担相同任务。

4：数据库读写分离-数据

     解决数据库高并发读压力。有些数据每次请求都不相同，无法放入缓存。

读写拆分。

5：CDN-网络缓存

     访问量大，网络压力大，通过动静分离，购买CDN服务。

动静资源访问路径拆分

6：分布式文件系统，分布式数据库-数据

     解决文件，数据的海量数据存储，写入，检索问题。

多个机器协同做一件事（数据拆分到多个节点）

7：NOSQL,搜索引擎

       针对特定问题弥补数据库的缺陷。

任务特色部分拆分-通用方案中拆出专用（将任务中特定的部分拆给更合适的对象处理）

8：应用服务拆分

      应对计算与扩展性的压力。

      不同服务压力不通，拆分后可独立扩充集群规模。

      不同服务方便独立修改上线， 人也方便安排。

      服务拆分是个技术，要拆好，高内聚低耦合。

任务按内容拆分（一个程序更少更专的事）

9：服务更精细的拆分- 微服务，中台，service mesh

       解决扩展，重用问题，服务拆分到简单粒度，更容易扩展与重用。    

       微服务更简单，方便维护，升级，服务重用。

       中台 就是把服务分层，将更通用的功能沉下来，方便重用。

      微服务某种程度可以说是中台的一种落地方案。

任务按内容拆分（一个程序更少更专的事），

各个内容中拆出共通的部分（中台，微服务中基础服务）由专程序统一处理。

servcie mesh 将非业务部分拆分

2.2.2互联网架构的方法论

1：用适合技术解决当前的问题

问题是伴随成长逐渐出现的，也在成长中逐渐解决问题。类似问题在不同阶段细节差异会很大，根据自己所处的阶段选择合理方案解决当下问题。能解决问题的方案越简单越好。

现有成熟技术可以提前使用，但前提不能影响当前阶段的需求，并且成本可接收范围内。

2：通用的互联网架构模式

各种互联网架构方案，方案实现上有差别但面对问题相通。都为了应对产品的复杂性在各方面增加导致的问题，满足增加不断增加高并发，高可用，易伸缩，易扩展的目标。因此各家方案间模式，提取出来作为互联网架构的模式，方法论。

1：横向分层-拆为多个步骤

     大型架构都采用的模式，每层负责一个单一的职责。上层调用下层。

     常见：网络层--接入层，网关-业务逻辑层-数据访问层-数据支撑

2：纵向分割-拆为多个简单问题

     soa,微服务，中台等技术都是对服务的拆分，只是角度不同。

3：分布式-拆到多个机器

各层次都可以拆到多个机器承担，把大任务分层多个小任务协作处理。

分布式服务，分布式文件系统，分布式数据库，分布式计算

4：集群与负载均衡--多个机器

相同模块部署到多台机器,lvs,nginx,

5：缓存

      将数据放到近处，加快处理的速度。思路也是拆为多个步骤，对结果保存，下一次节省步骤。

cpu从硬盘获取:硬盘->内存（缓存）->cpu

网络获取：客户->本地中转节点（缓存）->产品服务器

      CND,反向代理，本地缓存，远程缓存

6：异步-解耦

       将业务分成多个阶段，阶段间共享数据而不直接调用。将强依赖的步骤拆分为弱依赖。

       优点：流量消峰，提高响应速度，提高可用性。

7：冗余

防止服务器，网络故障。数据，服务器，网络都要做冗余。

数据库主从，主备，程序的主节点选举，多地部署。

8：自动化---目前主要在运维

把任务从人拆给机器 

自动监控报警，自动重启，自动扩容，自动部署。     

9：安全

多角度的安全方案，大多通用。

服务器安全：操作系统的各种安全加固，

网络安全：防攻击，防火墙

安全存储：敏感信息加密存储

安全传输：https,tls,国密等

应用安全：网关，对特殊权限的审计，异常信息检查（风险控制），编码转换防sql注入，xss攻击，前

端安全：脚本注入，app本身数据存储加密，各种身份多重认证(如短信，生物识别，口令要求复杂，重

要口令要求定时更换）,Oauth2.0，登录动态验证码

特殊应用防止信息抓取：如视频网站数据加密防止抓取，图片防盗链。

10：自动化

主要在运维，持续集成，部署，报警，重启，扩容等都可以自动化。

3： 互联网架构技术一览