一、三高如何划分：
常听的四个高：高可靠、高并发、高性能、高可用；怎么划分呢？
高可靠（针对数据），高可用（针对服务）
OLAP：On-Line Analytical Processing 联机分析处理， 大数据，追求高可靠
OLTP：On-Line Transaction Processing 联机事务处理， 记录实时数据，追求可用
OLTP联机事务处理，就是我们通常所说的关系型数据库，记录了实时的增删改查数据。 OLAP联机分析处理，是数据仓库的核心，是对OLTP的历史数据进行加工，分析处理，用于处理商业智能，决策支持等重要的决策信息。 区别：1.OLTP是明细的数据，OLAP是汇总数据 2.OLTP记录实时的数据，OLAP包含2-3年历史数据 二、架构是什么？
架构的目的：一切脱离场景谈架构都是耍流氓，架构的目的与架构师的目的一样都是降本增效。
架构是什么：是对场景抽象后得出的支撑骨架，场景包括：业务复杂度、数据规模大小、人员技术研发水平、时间成本、运维能力等。
最适合的架构：最适合的架构是对各方面场景折中（Balance）的结果。比如我们的团队之前熟悉openFeign,如果换成dubbo附带了学习成本，但是如果学习成本不大也是可以的。
架构的演变：架构的演变是场景驱动的。
三、架构演进：
四、Monoliths单体架构:(ALL IN ONE)
性能：指标分为qps与响应延迟两个方面。
redis在1c2g的情况下每秒10万qps(读)，单体架构优化到redis的水平已经很牛逼了，在业务场景中，10万+的qps很普遍，如果在100万的qps的场景中，单体架构无法满足我们的需求，这时我们可以让服务做到无状态化，然后部署多个节点，假设此时需要部署10台机器可满足需求，但当qps上升到千万级别时，我们需要部署100个节点，这个时候硬件成本巨大，本着降本增效的要求，更好的压榨硬件资源，我们应对服务进行拆分。
五、拆分：
谈到拆分，最常见的BDsharding,一般有以下4种：
其中最常用的是2、3 垂直分库与水平分表。因为水平分库，就是多个数据库表结构一致，然后通过数据取模放入不同的库中，但是我们查询数据的时候需要跨库跨表查询，很费事，但是水平分表是在一个库中建多张结构相同的表，查询的时候只需要跨表查询即可，如果不做水平分表，一张表如果数据量过多查询效率就会变低，如mysql(“MySQL”的正式发音是“My Ess Que Ell”（而不是“my sequel”） ),业内经验数据：100byte以下 5000万条数据性能下降，100byte以上1000万条数据性能下降，阿里巴巴建议500万（彩票一等奖）条数据时进行水平分表。
表结构可以这么拆分，我们的服务也可以进行水平与垂直拆分。按功能水平拆分，按业务垂直拆分
六、水平分层架构：
如我们都听说过的mvc架构模式：
按请求的请求的生命周期（功能维度）水平拆分成：视图层、请求控制层、业务逻辑层、数据访问层、数据存储层
那么主要的问题来了：我们是要将controller\service\dao这几个层拆成独立的模块，进行模块划分？还是拆成独立的进程、应用呢？如果拆成独立的模块，仅用于模块的划分，我们的颗粒度并没有变小，和单体还有什么区别，所以我们应该拆分成独立的应用。七、SOA架构——面向服务架构：
以业务的维度进行垂直拆分：
八、水平拆分与垂直拆分对比：
水平拆分才是精华，因为水平拆分按请求的生命周期进行功能拆分，请求的生命周期在每个公司都是一样的，我们常用的中间件很多都是水平拆分出来的，可以很容易的复用，至于垂直拆分，第一很简单，谁都能想得到，第二，按业务划分的垂直拆分每个公司都不同，普适度极低。
按水平与垂直一起拆分，那就是微服务。
九、soa与微服务的区别：
soa只是进行了垂直拆分，未进行水平拆分。
微服务既做垂直拆分，又进行水平拆分。微服务微在哪里？就是相对于SOA架构更加的小了。
十、微服务
微服务不是银弹：微服务不但需要写业务代码，还需要进行服务治理，业务工作与服务治理耦合在一起。
十一、service mesh(服务网格架构)：
service mesh 有人称之为微服务2.0，将服务治理与业务工作完全解耦开，service mash完全符合马丁·福勒的微服务理念。注意微服务的概念是马丁·福勒2014年总结的，而不是他最早提出的。
service mesh开源框架：istio
传统的微服务架构如果要升级为service mesh,需要换技术框架，成本很高，如果原来用的dubbo,我们希望dubbo与istio能实现控制链共用，数据链各用各的框架，dubbo出现proxy service less,支持xds协议，能够和istio控制链互相调用。
proxy service less出现的目的是传统的微服务升级为istio成本高，如果能打通istio的控制链，就能很容易升级。
十二、中台架构：
起源：
业务组件的复用。
他可以用前面几种技术架构实现，单体monoliths、soa、微服务、service mesh都可以。
十三、云原生架构cloud native
一切能在云上跑的架构都叫云原生架构，单体monoliths、soa、微服务、service mesh都可以。主要是运维侧，按需扩容，插入一层云，达到了服务与硬件的解耦。
十四、架构为什么演进：
为了更加极致的应用硬件机器，使得相同的设备条件下达到更到的吞吐量，前面说了，性能包括吞吐量与响应延迟两个，服务拆的越来越细，因为每一个进程之间都是网络通讯，导致响应延迟变大，难道说我们为了追求吞吐量，就不考虑响应延迟了么？
即使每次服务拆分后因网络通讯多出一毫秒，5个就是5毫秒，只要我们将响应延迟控制在合理范围内，大多情况下影响不大，所以我们不是舍弃响应延迟这个指标，只是觉得它还hold住。
十五、DDD(领域驱动设计)：
DDD与soa是标配，在soa时代DDD很火，但随着soa的没落、微服务的兴起，DDD销声匿迹，但是微服务有两大难题：服务治理与服务拆分，随着微服务的成熟，服务治理相关的各种中间件出现，服务治理已经不是难题，至于水平拆分比较成熟，剩下的难题就是业务方面的垂直拆分，而DDD本来就是指导垂直拆分的，所以DDD呼声很高，但是目前每个公司都是在DDD的基础上进行了精简，不是完整落地。目前没有标准的方案，让处于尝试阶段。
所以不要认为DDD可以在微服务里面一通百通，以前它的搭档是soa，后来变成微服务，所以DDD也要改变。
十六、单体架构（monoliths）的设计与实践:
优点：单体架构所有业务耦合在一起，一个人开发测试都很快很舒服很简单，部署与扩展也很简单，响应延迟也是最快的。简单开发、简单测试、简单部署、简单扩展
缺点：单体架构所有业务耦合在一起，比如内部分为用户、订单、交易三个模块，当交易模块达到瓶颈时，我们就需要扩展节点，这时用户、订单两个模块也会占用新的资源，造成资源浪费。另外如果开发人员多了人员与代码都不容易管理。
单体架构适合的场景：
- 业务场景简单、功能不复杂、开发人员少
- 创业公司，为了省钱
- 性能要求苛刻，如金融行业，证券公司，因为应用间通信有网络损耗，即使响应延迟多了5毫秒，结果也很严重。
十七、面向服务架构（soa）的设计与实践:
对单体在业务方面进行垂直拆分：
但是水平拆分才是精华，针对业务的垂直拆分无法做到复用。soa为了服务间解耦，引入esb（企业服务总线），esb具有注册中心、协议转换（网关）、字段转换配置、bpm(服务编排)、但是esb进行服务编排，相当于不同的公司针对不同业务需要定制化，所以esb不同公司不能复用，不能独立成为一个中间件。而且esb容易成为系统的瓶颈，esb就可惜了。
缺点：
- esb因为bpm也无法复用
- esb容易成为瓶颈
- 且sao没做水平拆分，每个应用还是大单体
十八、水平分层架构的设计与实践:
水平拆分即请求链路拆分，才分为网关层、业务逻辑层（logic）、数据访问层（das）、db,独立出很多中间件，如网关，每个公司都可以用。
网关：进行前置检查，筛选有效请求，过滤垃圾请求.
DB：可以是DB、Cache、mq、对象存储（oss）
oltp：rdbms(关系型数据库)、NOSQL、newSql
olap：ELK(Elasticsearch , Logstash, Kibana,ES提供搜索引擎，logstash日志的搜集、过滤、分析，kibana提供界面)、HBase；
业务逻辑层logic：包含我们的controller+service的,网关的存在降低了controller的重要性，controller可以做的很薄甚至没有。
水平分层做到 展示层与网关服务分离、网关服务与逻辑服务分离、逻辑服务与数据服务分离
十九、网关的作用：
请求鉴权，如登录鉴权
数据完整性校验，数据包是 定长Header+变长body,每种协议有自己的数据包协议，按协议校验。
协议转换，如http转换为tcp协议，因为服务内部可能使用的是dubbo协议（tcp）、pb（Protocol Buffer）协议（二进制），网关进行同一的协议转换，服务内部建议使用tcp协议，因为虽然http可读性高，但效率低，大致tcp是http的一百倍。
路由转发，我认为其最重要的功能，根据业务头的cmd路由到不同的业务服务,除了cmd,前面的请求鉴权也可以在业务头里面方token、userId等鉴权
- 限流、熔断、降级，系统级别的，但服务级别的也不可少
不同公司的filter不太一样
选型：java建议选gateway、go建议用APISIX,自研网关难度也不大
二十、业务逻辑层logic：
做业务处理
二十一、数据访问层das：
数据访问层的功能：
为什么数据访问层要与logic隔离开呢？人员利用？
因为业务逻辑层与数据访问层的拆分可以让人员的利用更加有效；数据操作最重要，交给业务能力强的人做，业务处理交给能力弱的人做；因为数据访问层不仅要做简单的crud，orm,还要做Sharding，sharding很考验技术含量，但是newSql支持数据层面的sharding，既然数据库支持了sharding，就不用了写sharding逻辑了（如果有数据库sharding的需求建议直接上newSQL，如TiDB），另外还需要屏蔽底层存储差异，它不仅仅是屏蔽如mysql与oracle的区别，更重要的是屏蔽oltp与olap的差别。 在微服务时代服务和表拆的都很细，如果再进行多个数据库聚合查询就很复杂，如果das设计的很好就可以避免聚合的情况，统计查询的界面上olap,olap对实时性要求不高，可以进行宽表查询(es、hbash),另外还有可能存内存。
二十二、异步架构：
mq处理的是写请求，读不经过MQ,上游写入mq就返回，然后mq向下游发请求，上游与下游各自都是同步的，但对于整个链路是异步的。
不是所有的写场景都适合异步：
cp的写不适合引入mq,如充值；ap的写适合写入mq，如发朋友群，微信发消息，如果失败会提示请重新发送;在真实场景中cp写远少于ap写的；
微信有引入长连接的概念，消息先发给mq，mq发消息去写，如果写不成功，依靠长连接，返回ACK,失败结果。c/s系统有长连接，b/s系统原来无长连接现在可用websocket,而(长轮询) 代价太大。
二十三、水平分层过多的缺点：
- 请求路径变长
- 响应延迟变高
- 定位问题变复杂，当然现在可以用apm
- 运维成本变高
二十四、微服务架构：
微服务既在业务领域做垂直拆分，又针对请求链路进行水平拆分，可做到优雅拆分。DDD可以指导业务领域做垂直拆分，但业界没有成熟方案，DDD是为了业务上的解耦，业务间高内聚，服务间低耦合。
微服务概念是马丁·福勒2014年总结的，而不是他最早提出的。
1.电商网站在业务领域做垂直拆分：业务领域
2.api层次进一步垂直拆分：读写分离cqrs
写请求重要性远远大于读请求，实际场景中，读远大于写，如10万读1万写，如果读大量的场景中， 10万读请求可能影响到1万写请求，如果写操作被丢弃，后果很验证。这个时候如果，读与写分开部署，避免影响写请求。AP可不拆，cp一定拆开。如果业务对数据一致性要求不苛刻(ap)，可以；但如果对数据一致性要求苛刻(cp，因为涉及到钱很重要)，如交易、充值；oltp与olap也应拆开
3.读写db拆分：？宽表怎么用？
如果服务读写分离了，返如果db不分离，db会出现瓶颈，这时可以采用db主从同步,写在主库，读在从库。
主从同步分为异步同步与同步同步，异步的话时效性查，如果业务对时效性要求不苛刻(ap)，可以；但如果对时效性要求苛刻(cp)，如交易、充值，则可以用同步同步数据，但是如果同步，响应延迟变长，影响系统的性能。如果qps与tps更大，这需要sharding数据库，是否分库看qps与tps,是否分表看数据量。实际应用中，如果业务中有涉及到sharding的操作，建议直接引入newSQL在db层级解决问题，因为sharding很复杂，还不容易扩展。
搜索、推荐为什么一定要拆开？
4.水平拆分：
其中，gateway是SAAS,是中台（因为不会分为用户服务的网关、交易等的网关，而且是业务中台，因为网关处理的都是与业务相关的；而DB/Cache是技术中台），gateway的作用有：
- 请求鉴权
- 数据包完整性校验
- 协议转换
- 路由转发
- 系统级别的限流降级熔断
service mesh是微服务2.0，不同应用可以用不同的语言编写，这在微服务1.0的时候是不可能的，1.0时我们所有的服务用同一种语言，如java,这才是马丁富勒提出的微服务，如果想用多种语言实现微服务，则需要将业务服务与服务治理分成两个应用，服务治理对每个应用都是一样的，一样的东西我们可以剥离出来用一种语言写，如go,其他的如网关、业务逻辑层、das等可以用不同的语言写。
5.微服务架构设计与实践（案例）：
二手交易平台：
搜索持久化层用的es,推荐持久化层用的redis,注册中心与配置中心都是技术中台。
架构的目的：降本增效（快速迭代，持续交付，降低人工与时间成本；拆分的颗粒度细更加极致的压榨硬件资源，降低硬件成本）
6.微服务适用场景：
问题：erp系统为什么不适合用微服务系统？
- 需求层面：
微服务是为了快速迭代，持续交付，如果需求成熟，迭代的频率低的系统如ERP、oa、工单、考勤、在使用方的角度上不需要使用微服务，但在生产者立场上是需要的，因为迭代的频率低可能会丢掉市场。
- 性能方面：
性能分为吞吐量与响应延迟，用了微服务以后，因为网关，业务逻辑层，数据访问层可以无限扩容，所以吞吐量上升。但是由于拆分的层数多，应用之间有网络消耗，所以响应延迟高了。所以如果系统对响应延迟要求苛刻就不能使用微服务，如证券里的量化交易等。
- 数据一致性：
cap，cp模型保证数据一致性：
单体只有一个db，只有本地事务保证数据一致性，但是微服务，分了很多DB,这时需要考虑分布式事务的问题。cp在维服务中较难实现(XA、TCC、SAGA、AT)。
7.最普适的微服务架构：
DNS域名解析：（如：dns pod,已被腾讯收购，分为收费版与免费版，作为企业要用收费版）；
CDN处理静态资源：先抛开Cdn，一般我们开发中（css,js，html）比较轻量级的访问nginx找路径,(图片，视频)重量级的用Object Storage存（如，fastDFS/MinIO）;这些静态的资源，如果服务器在深圳，这北京的访问由于距离长会慢，所以需要CDN(CND实际上就是缓存cache，在每个城市、每个区、每个县都有)cache提供者就是一些cdn厂商。（阿里与腾讯的cnd都不错），cnd在每个城市、每个区、每个县都有，当访问的时候，会选一条最近的路径。如访问
cdn.andawell.com/1.jpg,如果cdn有就返回，没有就回源，即去服务器（nginx/Object Storage）查返给cdn，然后在给用户。动态接口数据： lvs+keepalive:ip漂移，保证系统高可用；
8.微服务不是银弹：
业务需要进行服务治理，使得服务迭代变慢。所有的服务都需要做比如服务注册与发现、负载均衡、失败重试、熔断\降级\限流、链路追踪（监控）；
基础组件升级困难，影响基础设计团队的交付能力与交付速度，比如说在年底冲业绩的时候业务团队主要赶业务服务，服务治理的不需要升级也行，但对于基础团队，如果不升级就完不成kpi,导致矛盾。
业务每种语言一套基础设施，成本巨大，如网关是java写的，网关的服务治理需要用java写，业务逻辑层是用php写的，业务逻辑层的服务治理需要用php写，数据访问层是用go写的，数据访问层的服务治理需要用go写,成本很大；所以说马丁富勒说了微服务就是微服务2.0——服务网格（service mesh）;我们应该让业务团队专注业务，服务治理团队专注服务治理，物理解耦业务研发团队与服务治理团队。一套基础设施支持多种语言，基础设施从应用程序下推，真正做到快速迭代，持续交付。
二十五、服务网格架构（service mesh）：
服务网格是基础设施层、用于处理服务间治理。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。
注意：它们与应用程序部署在一起，意味着应用程序要与代理部署同机，同机，可以是物理机、虚拟机、也可以是pod；
那问题来了，为什么要同机？原来我们应用A访问应用B，只需一次rpc，如果用服务网格，则如果应用A访问应用B，应用A需要先访问sidecarA,sidecarA访问sidecarB，最后sidecarB访问应用B，则需要三次rpc,一次请求变三次请求。但是如果同机部署，应用A直接访问127.0.0.1端口随便写一个如80就可访问sidecarA，这是虽然也经历一次tcp传输，但是应用A与sidecarA省去了服务注册与发现、路由、负载均衡，重试这些服务治理策略；且应用A与sidecarA之间使用长连接，所以虽然应用A访问应用B虽然有三次网络交互，但是消耗性能与需要服务治理的就只存在sidecarA与sidecarB之间，而且sidecar用一种语言写即可。而传输协议可以是pb等
那如果应用与sidecar放在不同机器上呢？不行，我们将他们放在统一机器上就是为了省去服务治理，放在不同机上，又引入服务治理的工作。
服务网格架构优点：
- 独立进程，独立升级（升级不用给业务打招呼）
- 业务团队能专注与业务逻辑本身
- 一套基础设施支持多种语言开发
- 业务团队和基础设施团队物理解耦
- 服务治理与服务本身解耦
开源的service mesh:istio
二十六、中台架构：
最早起源于芬兰的一家游戏公司，马云去参观以后回国内，逍遥子张勇总结出的概念。
中台架构不是技术架构，它首先是一个组织架构，组织上需要分中台与业务两个团队，它将一些通用的东西合起来进行复用，它用单体monoliths、soa、微服务、service mesh实现都可以。中台分为业务中台、技术中台、算法中台、数据中台。
1.业务中台架构：
不允许同级之间调用，只能自上而下金字塔型的调用。避免同级之间调用可以避免很多循环调用的问题。（循环调用是指的同一个api）
2.业务中台服务如何一键接入：
中台平台化