如何介绍系统架构什么是系统架构

编辑导语:做产品之前必不可少的一步就是设置好产品的系统架构。产品在运营过程中，会不断有不同程度的需求更新，所以前期搭建好架构是非常有必要的；笔者分享了产品体系架构的构建。让我们来看看。
架构，简单理解就是一个产品的结构。
架构离不开四个关键词:效率、适用性、稳定性、可扩展性。
效率：好的架构提升迭代效率；适用性：好的架构可以在小修小补之下适用各个业务需求；稳定性：系统是高可用的；可扩展性：无需改动底层；
b端产品需要解决企业不断发展中遇到的各种问题，所以随着新的商业环境、新的业态、新的模式，必然会诞生新的需求。
每个企业的发展方向、战略和组织都会导致多种多样的需求。在这种情况下，如何通过一款产品让上万家企业满意，变得极具挑战性。
没有好的产品架构，你做不到这一点。
很多产品架构不好导致的问题这里就不赘述了，主要包括:一有新需求就改底层；改变全身；当你满足新的需求时，你必须做出重大改变。
我们经常看到那种结构图，分层分块。不同的层做不同的事情，不同的块承担不同的角色和功能。
我们要明白，所有的架构最终都是为了提高效率，不能提高效率的都不是好架构。
01产品架构思维这里引入两个想法:
阶段1:线性化思维
也就是说，比如用户进入一个电商网站，找到一个商品，然后下单，付款，然后商家发货。用户确认接收，交易完成。
如果把这些环节都放到一个线性流程中，我们是否发现这个产品是单层的，所有功能都是有序混合的？
这样一个产品，一套代码，一旦涉及到一个环节的变动，就会动整个产品，动整套代码。
于是开始有了模块的拆分和前后端的分离。
模块的拆分可以很好的划分界限，就是把同一目标的一些场景功能整合在一起，把不同位置的场景功能排除在外。
那么，如果以后只针对模块A进行业务迭代，无疑会减少对整个产品的影响，而且会更加轻松高效。
随着业务层的横向划分，线性产品变成了离散产品。
毋庸置疑，线性比离散更快更高效，但随着业务需求的不断增加，任何速度都必须建立在满足需求的前提下，否则效率无从谈起。
第二阶段:模块化思维
模块化到底是怎么做到的？
比如从商品的角度来看，很容易理解，比如商品，那么商品中所有的底层数据以及各种商品相关的能力(比如商品创建、商品类目管理、商品货架管理等。)将包含在商品模块(中心)中。外部模块提供与各种商品相关的接口能力。
模块化的另一个优点是它降低了产品开发的边际成本。同样的产品创作，我一定会按照线性开发再做一遍。但是如果集成到一个模块里，我只需要让商品模块支持他业务的商品创建，稍微做一些扩展就可以满足了。
按照模块化的粒度，还可以进行拆分，如商品模块、商品基本信息模块、商品销售信息模块、商品活动信息模块等。
这些都取决于业务发展的需求。比如需要针对不同类型的活动制定不同的商品信息策略，而这样的业务需求数量多、频率高，就需要拿出这个模块单独迭代。
对模块化更负责的一点是定义边界，边界应该放在业务端，应该放在模块服务端。
我的原则是:相关性高、通用性强的功能放在模块服务端，相关性低、个性化强的功能放在业务开发端。
02什么时候需要设置中间站？以上讲的是单个业务线的模块化，但是随着企业的发展，多个业务线并行其实也很正常。这时候各个业务线都需要用到商品。例如，一个既想发展电子商务业务又想发展农产品业务的公司，都会涉及到商品能力的建设。
理论上，如果一套商品模块可以支撑两个业务线的商品需求，是否可以降低至少一半的开发成本？
那么问题来了。如果用一套商品模块来支撑两个商家的商品需求，会带来什么样的问题？
比如电商商品的数量是按照“件”来计算的，农产品的数量是按照公斤/克的重量来计算的，这就意味着商品模块需要支持公斤、克、件等多种计量单位。，这还不够。涉及退货、仓储管理、物流配送费用等。，并且它们都需要额外的方案兼容性。
最后整个商品模块会变得很重，任何不同业务的商品需求都会迭代到这个商品模块中，成为一个商品中心。
如果有4、5条线同时运行，他们对商品的需求不一样，那么商品中心就会变得非常沉重，而这种[沉重]甚至会反过来影响各业务线的商品功能，难以使用。

如何介绍系统架构 什么是系统架构

如何介绍系统架构什么是系统架构