当年自己的八股文背的其实还可以，但是自己的项目就只是一个单机系统，分布式？微服务？什么玩意？,还记得当时微众面试，是二面，在一个酒店房间，面试官笑嘻嘻的看着我，说让我先画一下我项目里面的农资电商平台，我脑子嗡嗡叫，啥？咋画，就一个安卓系统，一个前端页面，和一个后台系统？
大概长这样子
image.png
我擦，这也太简单了吧，我是不是该画复杂一点？或者说，我这个能叫架构吗？就这样，犹豫之间，毛线都没有画出来...我记得当时好像画了个这样子的玩意。。毫无意外的，嗝屁了～
第二次微众面试，毕业有快一年了，抱着试一下的心态，找了个师姐内推,那时候我在干啥呢，在搞爬虫。公司离微众比较近，就在金蝶那边,下班了溜过去，跟面试官吧啦了一会八股文，好家伙，没一会就掏出了一张纸：
来画一下你们现在这个爬虫系统的架构图！
当时系统的部署架构长这样吧，比上面的看起来还简单一点。
但是，我就是画不出手啊！！！心里想着太简单了啊！！这玩意能叫架构吗？
现在想起来，真的太憋屈了，年轻啊！那如果现在来回头看的话，能怎么画呢？
单体系统的部署架构图
爬虫系统的分层架构图
爬虫系统的业务架构
从上面的各个方向描述架构来看，其实即使是单体系统也能够画出不一般的架构图！（为啥当时我就不会呢！）
架构设计的三大原则：
每一条原则都符合我们大学做的秒杀系统啊！！
简单原则：一个系统就可以满足我们秒杀服务的所有动作，没有太多的中间件依赖
合适原则：在我们的实践项目中，单体系统是最适合不过的了。（主要是没钱啊！拆分服务，引入中间件，部署集群，都得钱啊！）
总结：
我们架构的优势：成本低，系统复杂度低，维护成本低，快速定位问题
劣势：稳定性差，并发量低，扩展性弱等
在梳理架构时，每个方案都有他的优势和缺点，所以需要了解你目前方案的优缺点。才能更好的向面试官展示你的系统！
好家伙，参加了个科创比赛，资金到位了，能买更多机器了，那不得将服务优化一下，拆分个微服务系统出来！
在这个服务拆分的架构中，我们做了哪些动作？
在单体系统中，我们的静态资源（Html,JS,CSS和IMG）可能都是通过我们服务端进行返回，存在的问题是：
那么通过前后端分离所带来的好处就很明显了：
随着服务的拆分，在部分功能的实现上，就会涉及到服务间相互调用的情况，例如：
在常见的实现方案上，我们会采用注册中心和RPC框架,来实现这一能力。而我们比较常用的实现方案就是zookeeper&dubbo。
为什么要使用RPC框架？
当我们提到使用RPC框架的时候，是否有去思考过，为什么要使用RPC框架？每个服务提供RESTful接口，不是也能够完成服务间通信吗？
这里就需要进行对比RPC和RESTful的区别了:
说完优点后，再来分析一下，RPC的缺点:
在上一个版本的服务拆分中,我们根据不同的业务边界，功能职责,划分出了多个子系统,而针对不同的系统，他所承受的负载压力是不一样的，例如：订单服务的每个请求处理耗时较长（其他服务压力不大），为了挺升我们的下单量，我们可以只扩容订单服务即可,这就是我们在服务拆分所带来的收益，性能使用率提升！
从上面的图我们可以看到，有些服务出现了不同的重影，每一个方块,可以理解为一台机器,在这个架构中，为了保证我们的下单成功率，以及下单量，我们主要将服务器集中在了订单服务。
除此之前，再来看看我们的中间件集群部署：
到这里为止，一般我们自己开发的系统，也就基本完成了整个秒杀系统的演进了。可能大伙一直有个疑问，为什么少了我们最熟悉的MQ呢？
在整个调用链路中，我都是以同步调用的方式去讲述这一个秒杀系统的架构,因为这个已经满足我们当前的流量诉求了，在架构设计的原则里面，提到的，合适原则，和演进原则。在当前满足流量需求的情况下，我们需要先思考引入消息中间件，带来的问题是什么？解决的问题又是什么？在权衡利弊后，才是我们决策是否要使用这个方案的时候。
在上述架构演进的过程中，我们通过服务拆分，垂直扩容，分布式部署等方式,提升了我们架构的性能和稳定性,对于我们自研阶段的架构演进已经是足够满足我们的流量诉求了，但如果我们想继续优化我们的系统，提升服务性能，可以从以下几个方面进行优化：
在上面的服务拆分阶段,我们就提到了资源动静分离,这里的静态资源包括：html,js,css,img等。我们活动阶段，可以通过后台管理系统，将商品服务中的活动的静态资源预热到CDN，加速资源的访问。
上面有反复提到，引入一个技术的时候，需要同时考虑它所带来的利和弊，那么CDN的风险是什么呢？
与上面的静态资源加速相对比，动态数据则需要通过缓存进行性能上的优化，老生常谈，为什么redis那么快？
引入redis带来的风险主要有:
MQ异步调用为什么能过提升我们服务的吞吐量呢？
主要原因在于，通过异步调用的方式，我们将消息投递过去了，就完成了这一次的请求处理，那么性能的瓶颈，由订单服务，转移到了秒杀服务这里。通过减少调用依赖，从而提升了整体服务的吞吐量。
MQ带来的常见问题：
能看到这里真不容易，感谢大家的支持。关于可用性这里，之前有写过一篇#《高可用实战》-B站蹦了，关我A站什么事？感兴趣可以看一下。
高可用主要可以从：
部署在同一个城市不同区的机房，用专用网络连接。两个机房距离一般就是几十千米，网络传输速度几乎和同一个机房相同，降低了系统复杂度、成本。
这个模式无法解决极端的灾难情况，例如某个城市的地震、水灾，此方式是用来解决一些常规故障的，例如机房的火灾、停电、空调故障。
在上述模式中，没办法解决城市级别的服务容灾，比如水灾，地震等情。而通过异地多活的部署方案，则可以解决这种问题。
但是每个方案都是存在利和弊的，那么异地多活的弊端主要体现在网络传输和数据一致性的问题上!