什么是高并发？
通常指通过设计系统保证能够同时处理很多请求
高并发系统有哪些指标判定？
响应时间(Response Time) (第一次发出请求到收到系统完整响应的时间)
吞吐量(Throughput）在一定单位时间内系统处理的用户请求数 如常见的(请求数/天、人数/天、处理业务/小时)。从网络层面来看可用常见的(字节数/秒)。
吞吐量公示计算
F=VU*RI/TF表示吞吐量，VU表示虚拟用户数量，R表示每个用户所发出的请求树。T表示性能测试所使用的时间长度。
- 每秒请求数(QPS) QPS是指服务器在一秒内处理了多少个请求,主要用来表示"读"请求。部署机器计算可以采用如下公示
机器数=峰值QPS/单台机器最高可承受QPS一般服务器后台 类似于阿里云管理后台可查看到服务请求数峰值。- 每秒事务数(TPS)服务器每秒处理的事务数
- 客户端请求服务端
- 服务端业务逻辑处理
- 服务端响应客户端
- 访问量(PV)页面浏览数量。
- 独立访客(UV)只记录访问某个站点不同的IP数量
- 网络流量 流入和流出流量
对比单体系统、分布式系统、微服务系统
- 什么是单体系统？
单体系统即一个应用程序，所有的业务代码都在一个应用当中,所有的表都存放在一个数据库当中。
单体系统面临的问题:
- 需要频繁合并代码分支，影响开发效率
- 多人协作耦合度过高,测试效率低下
- 开发节奏混乱,代码冲突频繁
- 代码模块层次越来越复杂,业务边界变得不清晰
- 项目越来越庞大,技术架构升级变得困难
- 什么是分布式架构?
分布式架构是指，将相同或者相关的应用放在多台计算机上运行，分布式架构就是将一个系统拆分为多个独立的应用，组成一个整体,共同完成任务。、
分布式架构的局限性
- 开发者在开发应用时需要考虑当前应用的API模块，如果因为业务需要改底层逻辑,则这种修改会影响API模块。
- 外部的服务器需要依据自己的业务向服务提供方提出响应的需求.服务提供方可能只是改动了API模块，但是对于整体来讲都需要 重新部署变,影响服务的稳定性。
- 什么是微服务架构？
- 微服务架构是由单一应用构成的小型服务,拥有自己的进程。
- 微服务是依据业务功能设计,以全自动的方式部署,和其他服务之间通过HTTP API的方式通信
- 微服务会使用最小规模的集中管理技术,例如Docker容器。
- 微服务可以使用不同 的语言编程。
微服务架构的特点:
- 通过服务实现组件化
- 围绕业务能力来组织开发团队
- 去中心化管理(每个团队负责自己团队内部的服务、负责开发服务构建等一系列操作,做好自己的事情即可)
- 去中心化数据存储( 让每个服务都拥有自己的数据库)
- 基础设施自动化(在微服务架构当中,所有的服务都是独立的,数量极多,如果人工构建,工作量巨大,所以微服务架构必须通过自动化的形式来构建)
- 充分考虑 故障(因为微服务之间是通过进程间通信的交互,所以失败的概率是很容易发生的事情。所以我们应当知道微服务架构并不是解决 所有应用问题的万能Key)
微服务架构思考的问题:
- 增加了复杂度。单个应用变成多个应用，不仅会造成服务数量的增多,也会代理交互模式的变更
- 服务间的通信会变的复杂。应用之间通过进程之间RPC/REST框架调用，这种方式要求调用方考虑到success或者fail的情况。服务调用者如何实现异常感知等是复杂的
- 微服务的边界划分？
- 在设计上面如果划分过粗,随着业务的层面上升,又会回到单体应用的臃肿
- 如果设计过细，服务数量会变得更多，则运维维护也变得随之而来的困难，增加服务链路的监控难度，让整个调用链路变的复杂化。维护成本巨大。
- 保持数据的一致性非常复杂。微服务架构中的服务可能使用的是不同的数据库，关系型数据库、非关系型数据库等，在数据库之间保持数据一致性是一件值得思考的事情。
- 对运维团队和开发团队的要求更高。因为每个服务的数量很多,所以运维团队不仅需要维护种类饭多的数据库和消息中间件,还需要持续集成自动化部署。
- 开发流程复杂。建议将微服务的团队按照服务的方式进行划分。每个团队复杂一个或多个微服务的开发、测试、构建运维等。
