系统的复杂性包括了技术复杂性和业务复杂性。
有人抱怨道：我做的系统一点都不复杂，你看我们数据量不大，用不上分库分表，业务也不复杂，单体系统就够了，什么负载均衡和集群也没有，流量也不大，高并发和分布式也没接触过。
何为技术复杂性，我上面提到的都算，随着业务的发展，我们的系统架构需要支持大数据和高并发，因此复杂的系统架构孕育而生，在数据库层面要考虑分库分表，读写分离，主备切换；
为了提高查询性能和单点问题，分布式缓存必不可少；
为了销峰限流和服务解耦，分布式消息中间件也要用上；
大促期间，为了保证稳定性，还要机器自动伸缩，服务降级、服务隔离、服务熔断、服务限流等都是常用套路。
此外，分布式还有分布式调度系统，分布式监控系统，分布式日志系统，分布式链路采集等等。事实上，所以系统都是分布式的，单点故障是无法忍受的。说到这里，你觉得这系统太复杂啦。对的，为了构建高可用，可伸缩的分布式系统确实复杂。
但是，技术架构只是技术复杂性的其中一块罢了。
试想，一个复杂的算法算不算技术复杂性呢？我觉得也算。一个好的算法，可以帮助我们解决很多复杂的业务问题。
这里，对于我们非算法工程师而言，如果能把业务问题转换成算法问题，我就可以把人工问题转换成智能化，那么我们的业务离商业智能又迈进的一大步。
说 AI 可能远啦，聊点近的，比如延迟队列的“时间环”算法，ZK的会话分桶算法，限流的令牌桶等，很多偏业务实战方面的落地也可以让我们做得事情充满含金量，换句话说，吹逼层次可以提高了好几个 Level 哈。技术复杂性，还可以是解决多数据源的聚合查询问题，解决数据多写同步以及一致性问题等。抛砖引玉，仅供参考。
业务的复杂性在于：不同业务与业务之前相互作用与干扰。
做过 2B 产品或者项目的小伙伴应该非常理解我所说的含义，因为适配不同企业和商家做定制化需求会导致产品越来越无法通用化，尤其 ERP 这种强业务定制的系统。
那么，为了维护多套类似的逻辑和代码是成本巨大的，因此设计可扩展性的系统尤为重要。很多时候，我们对需求的变化是不可预期的。这种不可预期性恰恰是业务复杂性所在。
事实上，架构设计都是基于当下的设计，一个设计的好坏在于：它是否可以快速地支持业务。换句话说，我设计的系统满足了当前的业务，但是它后期无法可扩展，那么这个设计是好是坏呢？此外，我们根据领域模型作出了良好的设计，但是随着业务的发展，每个模型耦合越来越重。
那么，请思考是领域模型不合理，还是架构设计的不合理，还是业务发展的太快了呢？或者，再思考一个问题。一个公司觉得业务中台的概念很好，也打算落地实践，但是呢，它的业务比较单薄，那么，此时它设计的业务中台具有通用性吗？我个人感觉，不太好说。
事实上，需要不停的业务滋养，只有滋养中才能从最初仅提供单薄业务功能的服务逐渐稳定成一个解决具体问题的业务领域模型。设计模式的有一个模式叫做「模版方法模式」，它的核心思路在于把公共的流程固化下来，把差异点移交给具体的业务方去实现。是吧，只有我们有足够多的业务场景，我们才能沉淀出那些是公共的逻辑，那些是可扩展点，然后在业务设计过程中，我们可以在本业务实现子类做自定义实现，或者提供 SPI 给业务介入方扩展。
你以为我说到这里就结束了吗？当然，不是。我更多的是想引发你的思考以及我们思维的碰撞。例如，很多人抱怨自己是 CRUD 工程师。
我觉得这些人太小看自己的价值了。业务的价值和复杂往往不是 CRUD，而是业务背后的价值思考。线下的业务线上化，传统的东西在线化，那么它就具有结构化存储的能力，可以和其他数据协同，那么，它就有价值。
此外，你是不是可以把 CRUD 的流程自动化，本来一天搞定的东西，你1分钟就搞定了，然后在花59分钟来实现业务差异性。可以了吗，当然不行。你是不是可以把59分钟在压缩压缩，写一个框架，把多分支的问题通过策略模式+工厂模式搞定呀，固化流程通过模版方法模式搞定哈，然后观察者模式、适配器模式、代理模式、责任链模式、状态模式都可以用一用。事实上，很多设计模式是解决复杂业务场景的可扩展经验套路。
最后总结一下，系统的复杂性包括了技术复杂性和业务复杂性。我们一起畅聊，学习，成长，打破认知的局限性！！！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
