一个典型的大型互联网应用系统使用了哪些技术方案和手段
一、面临的挑战
高并发
高性能
高可用
海量存储
海量服务集群
巨大的沟通成本
安全
网络环境复杂
二、应对手段
1.前端架构
动静分离
CDN
如何感知变化?前端是单独部署的服务器,每次使用 webpack 打包的时候会检查静态文件是否发生了变化,如果有变化会对静态资源进行 hash 重命名,在 html 中引用的也是重命名后的资源。
图片服务
反向代理
2.网关架构
nginx
lvs
缓存
3.服务架构
微服务框架:springboot,springcloud,thrift,dubbo,cache,redis,memcached
微服务设计:DDD
服务发现:zookeeper
异步化手段:消息队列 rocketmq,rabbitmq,kafka
垂直拆分:按照业务拆分
水平扩容:docker
集群
CAP,P:分区容错性,不同的子网络就是一个分区,比如一台服务器放在北京,一台服务器放在天津。C:一致性,客户端无论在何时何地访问,都能拿到最新的数据。A:可用性,任何时候都不能宕机
三者最多满足两个,CA,CP,AP,但是分区容错性基本总是成立,因为现实就是存在北京的可以访问,但是天津无法访问,所以现实情况基本无法做到 CA。
现实中如果保证高一致性那就要接受局部不可用,如果做到高可用那就要接受数据一段时间内不一致(比如 cdn 服务的图片更新,不能因为保证一致性就牺牲掉所有用户访问)。但是对于数据库来说就需要保证高一致性。
应用层服务往往选择的是高可用和分区容错,做到最终一致性
服务治理
什么是服务治理
不管是什么事物需要”治理“,那一定是该事物存在一定问题。当服务承担的业务职责变多变大,那随着更多问题的到来,服务治理开始变得必要。服务治理也与技术架构本身息息相关。
企业为了确保事情顺利完成而实施的过程,包括最佳实践、架构原则、治理规程、规律以及其他决定性的因素。
治理目标
服务高可用,高性能,安全
治理的内容有哪些
单体服务:内部逻辑变得复杂,扩展性变差
微服务:
1.服务注册与发现。单体服务拆分为微服务后,如果微服务之间存在调用依赖,就需要得到目标服务的服务地址,也就是微服务治理的”服务发现“。要完成服务发现,就需要将服务信息存储到某个载体,载体本身即是微服务治理的”服务注册中心“,而存储到载体的动作即是”服务注册“。
2.可观测性。微服务由于较单体应用有了更多的部署载体,需要对众多服务间的调用关系、状态有清晰的掌控。可观测性就包括了调用拓扑关系、监控(Metrics)、日志(Logging)、调用追踪(Trace)等。
3.流量管理。由于微服务本身存在不同版本,在版本更迭过程中,需要对微服务间调用进行控制,以完成微服务版本更迭的平滑。这一过程中需要根据流量的特征(访问参数等)、百分比、人群向不同版本服务分发,这也孵化出灰度发布、蓝绿发布、A/B测试等服务治理的细分主题。
4.安全。不同微服务承载自身独有的业务职责,对于业务敏感的微服务,需要对其他服务的访问进行认证与鉴权,也就是安全问题。外部网络,内部网络
5.控制。对服务治理能力充分建设后,就需要有足够的控制能力,能实时进行服务治理策略向微服务分发。
6.微服务框架本身治理,业务服务有感知,需要修改代码,框架升级需要重启服务,多语言支持差
7.监控服务的性能:由于服务组合,服务停机和性能低下的后果是严重的。通过监控服务的性能和可用性,当问题出现的时候能马上采取应对措施。
治理的手段是什么
单体服务架构向微服务架构演进。
服务发现,降级,限流,熔断,服务链路可追踪(把脉)
微服务治理,传统的做法都是需要引入微服务研发框架,配合控制平台完成如上服务治理能力的建设。比较常见的微服务研发框架包括SpringCloud、Dubbo等
监控报警
4.存储架构
分布式文件系统(hdfs,GFS)
分布式数据库(TIDB,OceanBase)
主从,主主,一主多从
Nosql(hbase,redis,mongodb,Couchbase,LevelDB,Neo4j,HBase),not only sql,non relational databases。分布式,非关系是 nosql 技术的典型特征
newsql,分布式,非关系,支持 sql 标准接口
5.后台架构
大数据平台
搜索平台
推荐引擎
数据仓库
hive、spark、fink、storm
6.数据中心机房架构
单元化
两地三中心(同城容灾+异地灾备)
双活
7.安全架构
运维准入
8.监控报警架构
数据采集
报警方案
报警通道
评论