系统架构 总结

最近一直在回顾和总结以往开发过程中用到的一些技术，例如redis、dubbo、kafka、zookeeper、spring、mybatis等等，发现以往对这些技术的理解仅限于使用方式和技术实现细节上，在脑海中一直无法完整的把这些技术串联起来，也不能很好的在实际场景中，根据不同的业务需求来做出技术选型，我想，这和我对IT系统架构演进过程以及每种架构模式应对的业务场景及带来的问题不是很清楚有很大关系，所以借此片文章，来总结一下对架构的理解。这篇文章准备作为现阶段学习和总结的一个主线，持续更新和修改。

我总结自己是一个爱学习但不善于思考的人，所以，虽然在很长的时间里花了大把的时间去学习，但是收获并没有想象中的大，可以说事倍功半，主要原因在于缺乏思考，虽然现在年纪大了，不过能及时认识到自己的问题，也是极好的，鲁迅老先生曾经说过，种一棵树最好的时间要么是十年前，要么就是当下。

那对于我们程序员来说，每天面对最多的就是无穷无尽的crud、与产品经理互相伤害以及由此引发的对人生意义的思考，曾经我以为crud没有意义，愤然离职，但是直到此刻，我才意识到，无论是curd还是与PM的互相伤对我们程序员来说都非常有意义，关键就在于如何“思考”。如果在curd的时候想一下每一次代码的执行流程，如果在撕逼的时候能想一下业务背后的逻辑，或许会有完全不同的结局。

写了这么多废字，下面进入主题。

首先，聊聊架构是什么。架构架构，就是架子的结构，架子是支撑一件东西的主体结构，例如下面这个哥们

但是架子并不是一成变的，上面的兄弟是人的架子，但是猫狗虫鱼豺狼虎豹的架子并不是这样，每种动物的架子都有他自己的结构，所以总结一下，架构就是支撑起某样东西的架构对应的结构，在不同的领域，架构的具体体现也不一样，例如，在建筑领域，移动楼的架构就是主题房梁，有高矮胖瘦之分，这个架构的主要作用是支撑起每个格子间或者每一个家庭，在人力资源管理领域，架构有多叉树（原谅我不知道专业术语）结构和扁平化结构，作用是支撑起一个组织的人员管理等等。

那反观IT系统架构，体现形式有单体架构、集群架构、分布式架构、Service Mesh架构，这些架构需要支撑起我们的业务，为老板赚钱。不同种类的架构都有其自身的优缺点，针对的场景也不相同。

1946年世界上第一台计算机“艾尼阿克”在美国诞生，到后来ATT的Unix系统，再到1991年发布的第一版Linux，计算机操作系统经过了半个世纪的发展逐渐走向成熟，于此同时，计算机硬件也在摩尔定理的指引下高速发展，直到最后PC的普及，促进了Web1.0到Web2.0的进化，再到现在，智能手机的普及，缔造了移动互联网，随着5G的发展，万物互联可以说指日可待。在技术发展的过程中，IT系统作为互联网世界的最小单位，也在不断的进化。

先来说说简单的架构模式-单体架构，从最初的LAMP到现在的SpringMVC+MyBatis都属于单体应用。早期，由于互联网发展初期用户基数较小、因为相对比较简单，采用单体架构，把所有东西都放在一起，也能够很好的支持业务，同时，部署简单，可以快速响应需求。即使是现在，对于一些小的服务还是会优先采用单体架构，。

在单体架构的基础上，如果在服务性能上无法满足需求，可以做对等集群部署，前端通过nginx或openresty做反向代理，数据库层的读写分离，一般这种集群架构能够支持很长一段时间。

在集群架构中，经常需要面临的一个问题是会话状态同步，目前能想到解决办法有四种，分别是

• 通过tomcat提供的插件解决
• 通过spring session解决
• 通过共享会话缓存解决
• 通过ip（会话）粘连解决

对于前三种都没有见过庐山真面目，只实践过第四种，因为这种方式实现最简单，通过nginx配置就可以完成。不过目前比较流行的解决方案是基于类似JWT的无状态设计来规避这个问题，Session同步这个问题不管怎么解决都感觉不够优雅。

此时，如果系统在性能方面还是无法满足业务需求，那么就要请出解决高并发问题的三把瑞士军刀之一 - 缓存，实践证明，缓存可以极大提升系统性能，延长系统架构的生命周期。

目前比较流程的缓存技术就是redis了，redis是一个非常强大的东西，可以用来做缓存、内存数据库、消息队列、实现分布式锁等等，有人可能会说memocahe，我只能说没用过。

使用缓存时，我们面临的问题通常有两个

• 如何保证双写一致性
• 如何避免缓存穿透/击穿，以及缓存雪崩的发生

保证双写一致性也是一个比较让人头疼的问题，目前能想到的是把设置缓存过期时间作为保底，然后选择一个合适的缓存更新策略。跟新缓存的一般思路无非就是

• 先更新数据库再更新缓存
• 先删除缓存再更新数据库
• 先更新数据库在删除缓存

另外还有一些对性能要求极高的系统，例如秒杀，一般会直接屏蔽掉写数据库这一步，首先做缓存预热，然后服务直接操作缓存，后台在通过消息队列或定时器来将redis同步到数据库中，对于缓存穿透、击穿、雪崩这个老生常谈的问题就不在这里展开了，可以跳转到www.baidu.com

但是，随着流量、业务复杂度以及团队成员的不断增加，单体架构或集群模式带来的弊端越来越明显，产生大量的重复代码、业务耦合度过高、单次部署需要的时间越来越差等等，这时候就需要考虑对服务进行拆分了，拆分的时候，可以根据系统的特点，采用横向拆或纵向拆，如果业务边界比较明显，那就可以纵向拆，把整个服务拆分成不同的相互独立的子系统，但是如何业务之间的调用比较多，就需要考虑横向拆，把每一个独立的功能拆分成一个服务，独立维护和部署，这时架构也就演进到了SOA模式。

早期的SOA架构通常基于WebService实现，还有人说基于消息总线实现，由于笔者比较年轻，所以也没接触过。现阶段所说的SOA架构通常指的是基于Rpc实现的（这里可以拍砖了），SOA架构涉及两大问题，一是实现跨进程跨网络调用，二是服务治理。目前有很多比较有效的rpc框架，例如grpc、thrift等等，但是这些都不具备服务治理功能，算了我还是直接说dubbo吧，dubbo可以说是目前非常流行的一个实现SOA架构的框架了，它提供了包括服务监控、服务降级、集群容错等一些列高级特性，来解决SOA架构中的问题。

另外，在某些场景下SOA架构还设计到API 网关，这里的网关一般是我们自己实现的，主要用来做功能的聚合以及一些安全访问控制等。