架构相关的知识，不知道大家平时的关注度会有多少？基于我自己来讲的话，之前对此的注意力还是比较少的。
不过这些东西在我看来还是挺重要的，我们做测试的时候不能一头就扎进业务里面，如果能对整个系统架构有一个宏观上的理解，我相信，对于你后面的业务测试、性能测试，或者面试（别问我怎么知道，吃过亏o(╥﹏╥)o），都是会有帮助的。
今天先来梳理下架构的演进。
一、单体应用
单体应用，其实就是不管啥功能都写在一个应用里，比如电商系统里常见的用户功能、商品功能、订单功能等等。
现在回想起刚入行的时候，测试的系统就属于这种单体应用。
那是给ZF做的一个“大”项目，名头是真的大，费用应该在大几千万吧，啧啧。
项目虽然“大”，但是工期紧张、人力有限。因为公司属于国企性质，正式坑巨少，我机缘巧合的成为了其中一份子，也是唯一的测试人员。实在需要人的时候，雇佣了外包人员来一起开发和测试。
所以在这种情况下，单体应用的优点就体现出来了：
- 简单粗暴，所有功能一起打包，直接部署。
- 本地调试方便，直接启动整个项目，调试都在一个进程内，没有冗长的调用链，方便快速定位bug。
- 本地函数调用，没有网络调用的开销。
- 有问题了可以快速回滚，因为只有这一个应用。
但是现在回过头去看，这种单体应用的缺点也很明显：
- 系统耦合性高，当后面增加的功能越来越多，代码量巨增的时候，之前某个主程脑海中划分好的模块边界可能越来越模糊，导致调用关系混乱。
- 改一赠二出现越来越多，经常存在开发修改了某个功能，而导致其他的功能有问题。
- 某个功能有问题，整个一起回滚。
- 语言单一，不能根据场景选择更合适的语言。比如其中有个模块系统主要是大数据分析，用 python 自然更加合适，因为它有丰富的类库。
- 系统整体可用性不高，其中某个功能出现问题，很有可能影响到整个系统的运行。
- 系统不易于拓展部署，比如系统中有一个功能流量很大，顶不住了就要加机器，那么在新机器上还是部署整个应用，不能单独的部署这个大流量的服务，会造成一定的资源浪费。
注意
单体应用，并不是指应用只部署在一台线上服务器，通常会有多台，不然只有一台服务器，真挂了就彻底完犊子了。
二、微服务架构
随着业务的发展，单应用已经不能满足当前需求了，于是就把之前揉在一起的功能根据业务拆出来，成为一个个独立的服务。
优点是什么？
- 降低了耦合度，模块作用边界清晰，按照业务物理隔离。
- 技术选型多样化，可以选择最合适的方案
- 可根据服务单独扩展，其他不需要的依旧保持原样，资源合理化利用。
看起来很完美啊，解决了单体的痛点。但是，新的缺点来了：
- 涉及到多个服务的改动，会比较复杂，需要多方考虑影响面。上线之前也要确定好上线顺序，确定好每个服务的回滚方案。
- 出现问题，可能会涉及多个服务的回滚，互相之间会有影响。
- 从之前的单应用调用，现在变成了多个应用直接的交互，调用链路变长，带来了网络开销，同时也给定位问题增加了难度。
- 另外，为了让你的应用更可靠，还有考虑其他的异常情况，比如调用失败、因某些问题导致的高频调用，对此还得做些 限流、熔断之类的措施。
- 还有很多......
三、SOA
提到微服务，还得再提一下SOA。
SOA 是面向服务的架构思想，其实微服务也同样，只是两者的侧重点有些差别：
- 微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想。
- SOA 架构则是指一种拆分服务并使服务接口访问变得统一的架构思想。
SOA架构中包含了微服务的思想。
四、分布式和集群
这2个只要明确好概念就自然的记住了。
- 分布式：两种不同的组件合作对外提供服务。其实我们常说的前后端分离就是这样的，前端的js代码在浏览器运行，后端的代码在服务器上运行。那对于我们的系统来说，同样如此。
- 集群：通常指同一个组件存在多个实例，构成一个逻辑上的整体。比如我有个用户服务，但是我有多个服务器都跑这个用户服务，这就是一个集群。
通常，分布式会包含集群。
