《架构成长篇五》系统架构设计理念及思维（抽象扩展性能解耦）

前言

本篇会列出一些笔者认为的系统架构设计需要考虑到的点，欢迎讨论指正。

系统抽象能力：

我们去看一些比较有名的源码，它的底层无一例外，都是有着很出色的抽象结构。一个出色的抽象代码能够让逻辑非常清晰，让代码重用率最大化，避免重复造轮子的情况。抽象的能力是我们对面向对象认识的实际运用，抽象设计需要合理的运用重写重载和泛型（这些都是JAVA的基础吧，学的时候只是几个理论，不过真的想玩好这几个特性，需要长时间的思考和对生活的感悟）

高内聚低耦合：

代码直接的耦合往往会造成调用之间级联的修改，服务直接的耦合则有可能造成服务直接的级联瘫痪。解耦合是编码者与设计架构者共同关注的点。如何保证代码间的解耦，我们可以了解一下结构型的设计模式，诸如桥接模式，装饰者模式，组合模式等等，都是良好的解耦代码结构。那么如何让服务之间解耦，通常都会使用mq来做服务之间的交互，服务之间只以事件的发布订阅来交互（如今微服务之间大多采用rpc或者rest的方式进行调用，只要做好服务之间的熔断策略即可）。

扩展性：

扩展性是一个系统重要的指标，扩展性良好的系统能够轻易的应对需求的变更和业务的增长，是一个系统延续性的保障，扩展性强的代码足以反映出设计师的技术能力以及对业务的理解思考程度。

业务流程扩展：系统的流程都是时刻在变的（不然产品经理干什么活）。那如果每次需求变更，业务扩展都要修改主要代码，代码耦合度高，很容易造成牵一发而动全身的结果。对业务的抽象和流程的解耦既能保证扩展性，重用度；也能让代码逻辑更加清晰。假设整个商品的购买流程有“浏览商品”，“下单”，“付款”，“发货”，“收货”几步，如果把逻辑汇总在主干代码上，那么加一个购物车的逻辑后，那后面的逻辑可能全要重构，还可能引发状态异常的结果。如果把这些步骤抽离出来形成基础的组件，在套用一些设计模式，便可以很好的解决这个问题。

服务扩展：微服务的火爆足以说明服务扩展的设计理念对于系统的重要性，合理的服务拆分设计能够然后各个服务之间有很多种调用方式，单个服务只需要关注它自己的业务。代码结构清晰，职责单一。服务之间耦合度低，能让系统自由地做服务拼接，就像搭积木一样便捷。

横向扩展：横向扩展指的是不修改系统业务，通过横向扩展服务的机器来增加系统的吞吐量，一般会与一些支持负载均衡的中间件配合使用。服务的横向扩展不止能够增加系统吞吐量，还能提高系统可用性，预防单点故障造成的系统瘫痪，也给系统灰度发布留下了空间。一个支持横向扩展的系统同时也需要对集群部署下的业务做幂等处理，添加分布式锁来控制重复事件，包括缓存也要考虑到集群的统一缓存操作等等。

性能：

性能是一个系统规模壮大之后必须考虑到的因素，确保系统性能稳定需要工程师对高并发程序有良好的理解与设计。

缓存过滤与缓存命中率：一般系统的查询量都会远远大于增删改，例如电商，基本上十几次查询才会触发一笔交易，由此可见一个像京东淘宝等大电商系统中查询的并发量有多大，缓存的重要性不言而喻。缓存的使用也有很多重点，比如防止缓存击穿（个人推荐使用布隆过滤器），缓存穿透造成的缓存命中率降低，缓存过期失效造成请求瞬间压入db（针对业务配置缓存的失效策略，让查询能够尽量走缓存），缓存与db如何保持数据一致性等等问题，都是设计者应该针对业务来详细斟酌的。

前瞻性：

业务频繁更新时怎么确保系统对以后业务的兼容，这就需要设计者能够对系统业务有个评估，在系统设计期间对以后的业务变更以及业务量加以考虑。能够清楚的知道系统的瓶颈在哪里，在业务即将到达瓶颈时进行调整或重构。

异常监控：

开发人员都明白一个真理–没有系统是完美的，bug时时刻刻都可能发生。有一个好的异常监控方案能够及时检测到线上问题并及时处理。比较成熟的方案有zabbix，能够根据关键字监控服务日志，发送邮件提醒等功能，试想一下，如果支付系统故障了，一直在重复支付，几秒钟可能就损失几百块，时间久了…不敢想象，越早的发现bug损失就越少。

业务回滚设计：

异常出现造成的数据有误，需要有合理的业务数据回滚设计，通常会编写一套业务回滚的逻辑，基于事件来供出现异常后回滚使用；还有一种思想是基于数据的版本来管理，这种方式更适合与批量回滚，可以了解下mvcc机制，根据mvcc来实现数据回滚。

安全性：

xss， csrf ，sql注入，文件上传都是黑客常用的攻击方式，一旦有漏洞让黑客有机可乘，你服务器里的东西基本上是任由摆布了，轻一点的可能用来挖挖矿；服务涉及R，可能就会损失一大笔财产了。我认为身为IT界一员，了解一下黑客的攻击方式还是很有必要的。了解如何攻击，才能有针对性的进行预防。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！