互联网三高架构 一
一、认识互联网三高架构
1、有哪三高？
高并发、高可用、高性能。
2、围绕业务做架构
技术服务业务，没有业务就不需要技术。先挑业务，围绕业务做架构。
业务依靠技术支撑。
一家企业刚开始，没有三高，只是单体项目，只是不断地根据需求来进化。
3、架构师是什么？
KPA架构师 = KPI + PPT + API 。
不会业务也不会技术，不可取。
架构师应该具备的职能：
1、需要比产品还懂产品。
2、组织能力 + 管理能力。
3、部门内 + 跨部门沟通、协调能力。
4、技术能力。
4、架构师要干什么？
1、先了解清楚公司的前进方向和战略部署，围绕这两点设计产品。
2、熟悉项目组的同事。
3、达成技术栈方面的共识，尽量让团队使用现有技术。
4、理解业务，设计架构。
二、互联网架构的技术选型
1、选择合适的服务器
可以选择弹性云服务器，ECS，资源不够可以再扩展。
基本配置：2核、4G、5M带宽。
2、如何快速搭建项目
发现新商机需要快速出产品，避免错失良机。可以容忍不太好的代码。
搭建代码仓库 GIT。
工程结构 Maven，Gradle。
多人协作：maven聚合工程。
高可用：nginx 负载均衡 - 分布式部署，同时满足静态资源的调用。
3、Maven聚合工程
优点：拆分不同的模块，父模块 ---- 子模块1、子模块2、子模块3。每个人负责不同的子模块。
缺点：在各个子模块的开发过程中必然会出现公共的部分，这部分代码需要放到公共模块中，就导致了代码冲突的概率提高。
4、SLB（云服务提供）
如果nginx所在的服务器掉线，就会导致服务转发功能失效。使用云服务器自带的SLB转发给不同的nginx，可以避免单点故障问题。
5、简单的集群架构
依据以上四步的思考，就可以构建出一个简单的高可用集群架构，满足了三高中的高可用。
三、微服务架构基础
1、软件架构的进化
什么是微服务？常见的微服务架构 Spring Cloud、Netfilx、Spring Cloud Alibaba是什么？
架构的进化一定是基于某一种因素，往往是业务的变化影响的。
2、单体架构
特点：
1、所有的功能集成在一个项目工程中。
2、所有的功能打成一个war包部署到服务器。
3、应用与数据库分开部署。
4、通过部署应用集群和数据库集群提高性能。
优点：
1、项目架构简单，开发成本低。
缺点：
1、全部功能集成在一个工程中，对于大型项目不易开发、扩展、维护。
2、系统性能扩展只能通过增加集群节点，成本高、有瓶颈。
3、技术栈受限。
3、集群架构
解决了请求过多的问题。
在单体架构的基础上，单纯增加了tomcat服务器节点，使服务器从单台变成多台。
4、垂直架构
核心：解耦。
特点：
1、针对每一个服务做垂直拆分，提高可维护性。
2、每一个子服务都需要有一个自己的访问地址（二级域名）。
3、以单体结构的项目为单位做拆分，将一个大的项目拆分成多个小的项目。
4、项目与项目之间存在数据冗余，耦合性较大，上图中都存在客户信息。
5、项目之间的接口多为数据同步功能，通过网络做数据同步。
优点：
1、项目架构简单。
2、各个子项目之间的功能相对清晰，且控制了项目整体的大小。
3、可以实现异构，不同的项目可以使用不同的技术栈。
缺点：
1、冗余问题：项目与项目之间存在数据冗余，耦合性较大，上图中都存在客户信息。
2、全部功能都集成在一个工程中，不易维护。
3、性能扩展只能通过增加服务器节点，成本高。
4、信息孤岛问题：
5、复用性问题：
5、SOA架构（面向服务架构）
定义：以服务的方式提供当前领域的能力。
SOA的目标是以更细的粒度拆分服务，一般是以业务拆分出服务，实现子系统之间通信。解决信息孤岛问题和复用性问题。
特点：
1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各个系统提供服务。
2、各个系统与服务之间采用webservice、rpc等方式进行通信。
3、ESB企业服务总线作为项目与服务之间通信的桥梁，解决信息孤岛问题。
优点：
1、将重复的功能抽取为服务，提高开发效率，提高系统的可复用性、可维护性。
2、可以针对不同的服务制定独特的集群方案。
3、采用ESB减少系统中接口的耦合。
缺点：
1、系统与服务的界限模糊，不利于开发及维护。
2、虽然使用了ESB,但是服务的接口协议是灵活的，种类繁多，不利于管理。
3、抽取的服务粒度过大，系统与服务之间耦合性过高。
6、微服务架构
在SOA的基础上继续拆分，将各个子系统的服务再拆分，进一步提升复用性，提升扩展性，降低耦合。
缺点：
服务拆分地越多，越难以维护。这时候又需要合并一些服务。
7、业务架构
基础：对业务理解的透彻，可以做出业务领域的建模、业务边界的划分。
8、技术架构
基础：一致性考量、可用性考量、缓存、并行、并发、海量数据的处理。
四、微服务架构的框架
1、Spring Cloud Alibaba
Spring Cloud 是基于Spring Boot的微服务解决方案。
2、架构的组成
网关、负载均衡、注册中心、具体服务、监控中心、日志中心
3、架构的指标
并发数：同时服务的调用方的数量，包含以下几项：
1、并发的用户数。一部分在使用服务，另一部分在待机。
2、并发的连接数。用户和服务器之间的连接，一部分连接在传输数据，另一部分在待机。
3、并发的请求数。一部分调用静态资源，另一部分需要计算。
4、并发的线程数。在整个系统内，并发的线程数目。
吞吐量：单位时间内，能接收和返回的数据请求量。
特点：用户不能直观感受到一个系统的吞吐量。
1、看业务逻辑。
2、看请求数据。
3、TPS：Transaction Per Second。每秒进行的事务的数目（整体定义事务的 请求、操作、返回）。
4、QPS：Queries Per Second。每秒进行的查询量。
5、一个TPS包含多个QPS，每一个静态页面、动态数据都是QPS。由具体的场景决定。
平均响应时间：从用户的角度出发，响应的时间。
特点：用户可以直观感受到一个系统的吞吐量。
1、所有响应时间的平均值。
2、如何缩短响应时间？
可靠性指标：平均无故障时间。
1、从系统上线到当前时间 发生故障的次数 / 总运行时间。
① 指标之间的关系
决定了需要优化哪个指标。
1、并发数对吞吐量的影响：
在达到系统瓶颈之前，并发数越大，吞吐量越高。达到系统瓶颈之后，随着并发量的增加，系统压力越来越大，吞吐量下降。
2、并发数对响应时间的影响：
随着并发数的增长，平均响应速度先缓慢增长，到达一定程度后呈指数级增长。
3、平均响应时间对并发的影响。
从用户的角度出发，响应速度慢就重新发起请求，响应越慢，并发数越多，响应越慢。形成负反馈。
4、其他指标对可靠性指标的影响：
其他指标越差，可靠性越差。
② 指标的优化
1、响应慢了就增加并发数。
2、计算资源紧缺就降低并发数。
3、分流：
将原本指向一个系统的请求，分散到不同的系统上。
将请求到达系统前的各个阶段，对这个请求进行分流。
③ DNS负载均衡
DNS:域名映射IP地址，一个域名映射多个域名、多个域名映射多个IP地址。
DNS负载均衡：域名添加多个A记录（IP地址），这样进来一个请求的时候会实现自动分流，经过DNS后请求进入不同的服务器。
但是使用DNS负载均衡时，难以控制请求转发的链路，可能导致响应延迟很多。
④ CDN 降低网络延迟
CDN：将用户请求发送到距离用户拓扑距离最近的服务器。
由于网络负载、内容可用性、设备工作状况，服务器之间的拓扑距离是动态变化的。
有两个优点：
1、分流：请求进入不同的服务器，降低单台服务器的并发数。
2、让用户访问距离他网络拓扑最近的服务器，降低网络延迟。缩短平均响应时间。
缺点：
1、部署成本高。
2、数据同步复杂。