Week_04 作业 + 总结
大型互联网应用使用的技术与手段
1. 大型互联网应用的特点：
访问人数多，用户多，并发请求多 --- 高并发
请求多，系统会受限于网络带宽 --- 大流量
系统要7x24小时的运行，方便用户随时访问 --- 高可用
市场业务上竞争激烈，需要功能快速上线 --- 快速迭代
业务的扩展需要系统快速支撑 --- 可伸缩性
2.使用的技术和手段
技术的使用，是为了解决现实问题。从数据的角度看，前端进行相关业务数据的组织，后端提供对数据的支持，包括数据处理，以及数据存储。数据组织方式的不同，导致人员管理的不同，俗话说，生产关系需要与生产力协调。
数据展示
业务高度相关（大前端技术react, vue等）
数据传输
https，http，grpc，tcp/udp等
数据流量分流
CDN
分布式缓存技术
负载均衡技术（lvs，squid，nginx，traefik网关分流处理等）+ 服务集群化
针对瓶颈进行业务拆分，接口拆分
数据处理
请求流量的分离：一致性hash，缓存，数据库读写分离
业务服务拆分（微服务）+ 消息队列：rabbitmq，kafka等
搜索引擎在后端系统的使用
业务架构的模式与方法：事件总线型架构（观察者模式，DDD），微核架构，工作流架构，分层架构等
数据分析引擎spark
数据存储
分布式缓存：redis
分布式文件系统，分布式数据库：Cassandra，gluster，brfs，ceph，hdfs等
通用数据存储系统的高可用：mysql，redis，elasticsearch
数据监控运维
日志分析：ELK
调用链跟踪：opentracing
指标监控与展示：Prometheus + grafana
团队人员组织
1.0：web前端组+app前端组+后端组。从业务数据处理出发，团队组织使用分层架构，横向组织
2.0：业务功能1组+业务功能2组+...+ 后台组。业务快速发展阶段，分层架构使团队协调能力跟不上快速变更的情况，通过纵向切割组织，打通前后沟通的链路，提升协调效率
3.0：增加统领技术全局的架构运维组，统领项目全局的项目管理组。同时增加数据平台部，跟踪整个系统的各项数据，进行反馈，以便提供更好的决策支撑。
3. 架构的演变
快速开发原型，逻辑简单，组织部署简单，经测试实现基本业务功能，上线。
业务扩张，用户访问量增加：增加专门的数据库服务器，数据与业务应用分离，增强系统计算能力。
业务持续扩张，数据库压力持续增加：增加本地缓存和分布式缓存，缓解数据库压力。
业务继续扩张，请求响应速度跟不上节奏，达到了单服务器瓶颈：增加机器，应用服务集群化，通过负载均衡继续进行请求分流。
业务仍旧扩张，此时大流量问题随之而来，相应的数据库压力也随之上升：增加数据库服务器，读写分离，分散压力。
业务规模质变，面临高并发，大流量问题：网络边缘使用CDN，后端负载均衡技术+缓存集群+分布式数据+分布式文件系统，解决数据分流，与数据存储的问题，提升系统服务能力。
当业务规模到达一定程度时，对业务数据进行查询会面临比较多的问题：引入搜索引擎。
此时系统基本能满足了业务的实际需求，为了提供更好的服务和性能，方便部署与运维，降低运营成本：对业务服务进行拆分，微服务化，架构重构，引入中台
为进一步降低各种成本，引入大数据和智能化技术，优化各个流程
4.对工作的启示
系统闭环：各种软件系统，它首先应该是闭环，能自循环的，接受输入输出。基于此，一个完整系统的基本组成应满足：
基本的业务数据链条，支撑业务
对数据各个环节的监控与再处理，监控以支撑决策
决策选择反馈到整个系统，决定系统的演化方向
公司不同发展阶段，在整个闭环系统中，有不同的侧重时刻。
在系统闭环的大前提下，系统中自己的角色与位置，决定了个人思考与工作的方向
业务层的，需要思考业务数据链条的实现，以及整个链条中制约效率的瓶颈点
运维运营层的，需要产出数据，支撑决策，同时，思考哪些点需要进行重点关注，以及运维运营效率问题
决策层的，需要在已有数据支撑下，做出选择，针对整个系统的瓶颈进行改善。有些情况下，需要进行试错。
对docker技术的思考
公司引入docker容器化技术，改善的是整个运维的效率，对业务的反馈有更快的响应。与此同时，将监控和运维系统也放到docker中，使管理更统一方便，降低成本，降低出错概率。
docker改善的是整个后端管理的生态，通过构建不同的镜像，进行快速的试错与比较，加速了技术调研的过程。以后架构的过程少不了docker这个角色
还未添加个人签名 2018.09.18 加入
还未添加个人简介
评论