最近在思考一个问题，是关于toB产品的性能优化的，不知道你有没有发现，我们身边接触过的很多企业级的产品，性能都一般，例如海外的oracle、sap，国内的金蝶等。
为什么toB产品经常会有性能问题？
这点是反常识的，因为大家潜意识中会认为，toB产品的用户量普遍不大，并发量不高，像淘宝那么大的并发都没有性能问题，你更不应该有。这就像你面试时在大谈性能优化，然后被人问到：就你们系统的那点数据量，为什么会产生性能问题？我最近在想这个问题时，突然意识到大家其实混淆偷换了问题概念，并发量/数据量并不是引发性能问题的必要充分条件，只是其中一个因素而已。他们与性能的关系，并非完全对等的：数据量很大时，可能引起性能变差；数据量小的系统，未必不会有性能问题。
那引发系统性能问题的因素有哪些呢？让我们来看toB产品有几个特点：
复杂的业务逻辑。toB产品的业务流程都比较冗长，导致业务逻辑和领域模型的复杂性都明显高于C端产品，这对系统建模提出了很高的要求，如果没有很强的功底，经常会写出大量条件极其复杂、多表join的SQL。因为如果不这样做，你可能得通过冗余多份数据、使用搜索引擎等方式去实现，这个复杂度是研发同学不想面对的。
高标准的用户体验。toB产品是为了支撑企业经营管理需要，需要为用户提供更方便、强大的功能以提升工作效率，例如：
页面展示的元素有时会极其丰富，往往要求在一个面板上展示跨领域的数据，字段越多越好
搜索条件和规则复杂，用户要求各种下钻、上拉，反正什么都能搜到
个性化的管理端需求。管理者需要看到更广阔的数据，数据权限的控制会因人而异，例如：
上级希望看到下级及汇报线链路下的数据，这要求业务单据的查询逻辑和人员组织架构耦合在一起了
单据的维度和业务的岗位工种绑定，这要求在查询前做各种维度过滤筛选。
数据跨系统交互的复杂度。toB的产品业务数据流一般很长，一个子系统要完成一个功能，往往需要和多个上下游系统交互，例如我们经常需要在一个业务用例中去调用外部系统接口，有时甚至是批量的，导致很多接口非常慢。当前，我们说解法通常可以改成做异步化或采用最终一致性方案处理，但这个复杂度也是很多研发尽量想规避的。
综上所述，toB产品的性能优化并不好做，有时甚至高于C端产品。toB系统的设计复杂度是挺高的，如果沿用在C端产品的一些简单粗暴思路（例如分库分表、接口粒度过大、事务考虑不严谨），就会吃苦头。一个好的企业级产品，如果要有流畅的体验，往往在设计上要下足功夫。隔行如隔山，大家在面对技术问题时，还是需要理性、客观分析。
