这两天在跟客户讲公司的产品架构，同时简单讨论了目前存在的问题以及客户想要的架构。空闲时间就想了想 2B 类产品的特点（可能仅限于云计算类）。
相对来讲，2B 类产品最大的特点应该是：因为客户具有较高的话语权而带来的定制化的可能，导致开发产品的人必须经常性地调整产品的架构以适应需求。在理想情况下，我们开发的产品应该具有如下的特点：
- 可插拔: 可通过配置开启/关闭特定功能。这个不只是 UI 上的调整，而且包括 backend 组件的上线/下线
- 可定制化: ui 的 logo ,配色，以及各种微小的功能，允许用户通过配置文件等方式来改变
- 多产品线: 不同客户的规模大小不同，多产品线比开发一个普适性的产品要简单的多。
但实际情况确是，产品总是从一种较为简陋的基础开始，不断地往上堆积功能，你无法从一开始就想出一个完美的架构来完美地适应客户的需求。这是一个不断试错，调整的过程。 对于参与其中的人员来说，会在很多时候感到痛苦。
- 对于产品来说，会发现新需求非常频繁，而且其生命周期也不长。
- 对于研发来说，需要在短时间内开发一个新需求，很难在这个过程中考虑整体架构的优化，如何重构。
- 对于测试来说，需要尽快地覆盖新功能的测试，性能等方面的可能无暇顾及。
而与此同时，2C 类产品最大的特点是：性能。当然，2B 类产品的性能也很重要，只是它通常处于一个可控的规模之内，而且客户对于产品的功能更为重视 。对 2C 来说，交付的不是一个可见的产品，而且一种持续服务的能力。用户不关心服务端的架构是什么样的，他们只关心这个产品好不好用，页面卡不卡，操作快不快。对于服务端的人员来说， 要考虑的主要有
- 性能好不好，如何在用户增长时架构能够水平扩展
- 如果有新的架构，能否尽量做到无缝切换，让用户无感知。
作为一个研发人员，在这两种商业模式中能锻炼出不同的能力。前者主要是产品设计，交付，后者主要是性能优化，深入底层的 debug 能力。但从根本来讲，仍然是有很多共同点的。 一个优秀的架构设计，仍是问题的核心。
从技术上来说，Emacs / Code 这些软件的成功对我们来讲就是非常有借鉴意义。从一开始，他们的设计就是 core + plugin 的模式。core 的功能够用，但不够全。plugin 补全了这一块。 在 2B 类的产品开发中，每一个需求我们都应该想一下：这个能否可以做成 plugin 以及是否可配置。
从商业上来说, iPhone xr/xs/max 等分不同产品线的手段也是类似的。你无法开发出一个能够让所有客户的都满意的产品，那么不如分几条产品线。但是要尽量让他们之间有一个保持稳定的 core。