HTTP 传输协议
RPC 远程过程调用； 当然也有本地过程调用；
DNS 域名系统；将域名和IP地址相互映射的一个分布式数据库；
DSF 分布式服务框架；
单体应用（单体架构）的缺点：
1.系统耦合性高；
2.语言单一；如只能用java，不能用java+python；
3.系统不易于拓展部署，比如系统中有一个功能流量很大，顶不住了就要加机器，那么在新机器上还是部署整个应用，不能单独的部署这个大流量的服务，会造成一定的资源浪费；
分布式的缺点：
1.多个应用的交互，调用链路变长，带来了网络开销，同时也给定位问题增加了难度；
2.为了你的应用更可靠，因某些问题导致的高频调用，对此还的做些限流、熔断之类的措施；
3.环境变复杂了，增加了测试的复杂度；
客户端：用户端；
客户端包括：WEB客户端、移动客户端。。。
cookie、session、token都是围绕了一个点：身份认证；https://mp.weixin.qq.com/s/_V0cbcbO9w9SS2J2csd-MA
为什么要认证？
如购物网站需要登录，输入账号、密码，点击登录成功后，对服务器就产生一次会话session；
但是，由于http协议是无状态的，已经登录过的用户没法通过协议层把状态保存下来，所以下次再请求的时候，服务器还是不知道你是谁，有什么办法呢？session
session：当服务器收到登录请求之后，生成一个session id一起返回给客户端，客户端下次再请求的时候把session id一起带上。这时候每个客户端请求对应各自的session id，服务就知道怎么区分了。
cookie：客户端与服务器之间的会话，一般会使用cookie来管理；
客户端接收到从服务器端发来的session id后，会将其作为cookie保存在本地；
比如，我登录博客园，浏览器F12就可以看到保存在本地的cookie；
cookie、session使用过程中的问题；
1.由于服务器也要保存这 session 信息用户跟客户端传过来的进行比对，数量小了还好，太多用户登录，服务器要保存的内容就越多，会吃不消；
2.对于集群的服务器，A、B服务器要同步session 信息；
3.对于非浏览器的客户端、手机移动端等不适用，因为session依赖于cookie，而移动端经常没有cookie；
4.cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用；
token
其实token核心在于身份认证，想个办法既能解决认证，又不用服务器保存不就好了；
- 客户端使用用户名和密码请求登录
- 服务端收到请求，验证用户名和密码
- 验证成功后，服务端会签发一个 token 令牌，再把这个token返回给客户端
- 客户端收到 token 后可以把它存储起来，比如放到cookie中
- 客户端每次向服务端请求资源时需要携带服务端签发的 token，可以在 cookie 或者 header 中携带
- 服务端收到请求，然后去验证客户端请求里面带着的 token，如果验证成功，就向客户端返回请求数据
重点就是在于服务端可以不用保存 token。
比如，当第一次收到客户端传过来的用户名和密码时，服务器认证通过后，通过加密算法生成一个字符串当做 token。当拿到后续请求中的 token，服务器再解析这个token，可以从中获取关键的信息，从而判断该token的有效性。
目前接触到的大多数系统，都是基于token验证来的，因为它的优点更适合当下的系统应用环境：
- 无状态，可以更方便扩展
- 更安全，可以防止跨站请求伪造 CSRF
- 方便多平台跨域
- 可以标准化，比如基于JWT Json web token (JWT)
单点登录（Single sign on），简称SSO，SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统；
左移、右移；
左移，提测前的测试，如需求评审等；
右移，发布到生产环境后的验证；
质量内建
1.质量没法通过测试在短时间内进行一个本质的提高，
软件开发出来质量已经在哪儿了。如果已加公司有一定的时间成本去从根本上提高质量，并不是说让测试不停的测而是选择重构；
TPS、并发数、线程数
TPS:单位时间（每秒）处理的事务数；
并发数：同一时刻系统同时处理的请求数（相对并发，绝对并发）；
线程数：一般情况下，指的是虚拟用户数；
登录接口能够承受秒级1000并发，TPS 1000；
TPS=Vu（总请求数）/Time
描述系统的性能能力时，只说TPS是不够的，还需要考虑响应时间和系统资源使用率；如TPS都是1000，A系统的响应时间0.5S，B系统的响应时间2S；对于A系统，应该继续往上压，找出更好的TPS；对于B系统，差不多要进行调优了；
一般情况下，单接口的TPS，也可以是QPS（每秒查询事务数）。但是在实际的工作场景中，某一个T（Transactions）都会有若干个接口共同完成。很多性能测试工具（如jmeter），都提供了自定义（Transactions）的功能；因为这个（Transactions）才是描述客户行为的真实场景；不同的定义方法，TPS会有较大差异。不能为了追求数值上的好看，而忽略了真实场景；
通过TPS结合响应时间，才能更好地反馈系统的性能问题；