架构概论

一、架构概论

1. 顶层涉及
2. 按需、预期未来、规划企业架构
3. 业务全局触发，制定可落地的架构方案
4. 技术选型，难题解决规划
5. 方案与代码，广度与深度
6. 技术+管理（人，资源，技术）

二、基础理论PartI

1. 缓冲 Buffer：

          缓冲区就是一块内存区，它用在输入输出设备和CPU之间，用来存储数据。它使得低速的输入输出设备和高速的CPU能够协调工作，避免低速的输入输出设备占用CPU，解放出CPU，使其能够高效率工作。

         举个例子：啤酒理论，假如你想要喝酒，而你在30楼酒在1楼且你每次只能拿一瓶，那么假如你每次要喝5瓶就得上下楼5次。另一种选择是每次一次性拿箱子装拿5瓶， 那么这个箱子就是相对意义上的缓冲区，解放你这个人（cpu）4次上下楼的时间

2. 缓存 Cache 

缓存（cache）与缓冲(buffer)的主要区别

Buffer的核心作用是用来缓冲，缓和冲击。比如你每秒要写100次硬盘，对系统冲击很大，浪费了大量时间在忙着处理开始写和结束写这两件事嘛。用个buffer暂存起来，变成每10秒写一次硬盘，对系统的冲击就很小，写入效率高了，日子过得爽了。极大缓和了冲击。

Cache的核心作用是加快取用的速度。比如你一个很复杂的计算做完了，下次还要用结果，就把结果放手边一个好拿的地方存着，下次不用再算了。加快了数据取用的速度。

简单来说就是buffer偏重于写，而cache偏重于读。

ps：有时候大家要好好理解这些专有名词字面上的意思，对理解这些概念有好处，缓冲：缓解冲击，缓存：临时存储

3. 复用 Pool

      包括：连接池（复用连接）、线程池（复用线程）、对象池（复用对象）、字符串常量池（复用字符串常量）、享元减少三次握手成本、线程创建成本等各种成本，

4. 分治 Sharding

     分治，单机多机都使用，包括集群：分片集群，降低复杂度。HashMap也可以。

5.亲密（粘性） sticky

       某一个线程亲密到某一个CPU上；threadlocal；数据路由相同ip或session或商品分配到不同的负载机器上。
（可以通过配置负载均衡层的策略实现。例如，并发到来的时候，从C1客户端发来的请求被转发Server1上，从C2客户端发来的请求被转发到Server2上，这样在单机使用线程池，在线程池中单机加锁，要优于在多机加分布式锁，因为分布式锁要消耗网络通信的成本）
再比如，你小区有两个门，进门需要登记。你这次从北门登记过了，下次再从北门过就不用登记了，你从南门的走话还要再登记。

6. 权衡  Balance or trade-off.  

   做技术选型，相同的需求有很多方法能够实现，这时候你需要选择

三、基础理论Part2

1. TPS：TransactionsPerSecond

           意思是每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

       tps，即每秒处理事务数，每个事务包括了如下3个过程：
　　a.用户请求服务器
　　b.服务器自己的内部处理（包含应用服务器、数据库服务器等）
　　c.服务器返回给用户
　　如果每秒能够完成N个这三个过程，tps就是N；

2. QPS：Queries Per Second

          意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器（比如是读写分离的架构，就是读的服务器）在规定时间内所处理流量多少的衡量标准。

         qps，如果是对一个页面请求一次，形成一个tps，但一次页面请求，可能产生多次对服务器的请求（页面上有很多html资源，比如图片等），服务器对这些请求，就可计入“Qps”之中；
但是，如今的项目基本上都是前后端分离的，性能也分为前端性能和后端性能，通常默认是后端性能，即服务端性能，也就是对服务端接口做压测

        如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps
        如果是对多个接口（混合场景）压测，不加事务控制器，jmeter会统计每个接口的tps，而混合场景是要测试这个场景的tps，显然这样得不到混合场景的tps，所以，要加了事物控制器，结果才是整个场景的tps。

3. 吞吐量：

     吞吐量是指系统在单位时间内处理请求的数量，TPS、QPS都是吞吐量的常用量化指标

4. 并发数（并发度）：

       指系统同时能处理的请求数量，同样反应了系统的负载能力。这个数值可以分析机器1s内的访问日志数量来得到

5. PV（Page View）：

       页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。

6. UV（Unique Visitor）：

      独立访客，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。

7. 响应时间（RT）：

     响应时间是指系统对请求作出响应的时间，一般取平均响应时间。可以通过Nginx、Apache之类的Web Server得到。

8. DAU(Daily Active User)，

      日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。DAU通常统计一日（统计日）之内，登录或使用了某个产品的用户数（去除重复登录的用户），与UV概念相似

9.  MAU(Month Active User)：

        月活跃用户数量，指网站、app等去重后的月活跃用户数量

通常DAU会结合MAU一起使用，这两个指标一般用来衡量服务的用户粘性以及服务的衰退周期。 MAU、DAU分别从宏观和微观的角度对服务的用户粘性做了权衡，也可以这么说，MAU更像战略层面的表征，DAU更像战术层面的表征。通过这些宏观和细微的趋势变化，可以对营销及推广提供一些数据支持或者帮助。

商户可以采用自建的压测平台、阿里云的PTS、JMeter、LoadRunner或其他第三方的压测工具进行压测。为了帮助商户快速完成压力测试，支付宝提供行业压测平台来支持商户的压测工作。

四、AKF划分

三高：高可用，高性能，可扩展

x轴：数据的复制是全量的，基于主备，可以完成主从的读写分离，解决可用性，性能优化。
y轴：基于业务的拆分，业务太大超过了CPU算力或超过了硬件的负载，这时候我们按服务拆分。可以将不同的业务放进不同的Redis当中
z轴：在已经按照业务拆分了的情况下，并发量仍然很大，这时解决倾斜的方式：sharding，例如 0-99,100-199,...一般用代理来实现负载均衡。

按X轴（可用性）：

    全量

    主备

    主从  读写分离

    性能的优化

按y轴（业务拆分且高内聚） ：

   当超过了cpu的算力

   超过了它的内存的存储能力

   超过了它响应时间的合适程度

 相似业务/相似功能/相似数据结构

   性能提高

z轴（解决倾斜sharding）

  代理