写点什么

互联网产品架构成长

用户头像
superman
关注
发布于: 2020 年 06 月 29 日
互联网产品架构成长

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: 互联网架构技术一览





发布于: 2020 年 06 月 29 日阅读数: 106
用户头像

superman

关注

还未添加个人签名 2018.07.20 加入

还未添加个人简介

评论

发布
暂无评论
互联网产品架构成长