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