做架构就是做抽象，要把复杂的事情搞简单，千万别把简单的事情搞复杂。问题越复杂，架构越重要。所以做架构是为了解决复杂的问题。

下面从一个具体问题出发，分享架构设计的基本思路。由于本人的经验和能力有限，难免有不足或错误，欢迎读者指出问题并一起探讨。

接下来的内容，我们先介绍业务背景，然后思考如何设计一套技术系统，来支持业务的发展。

业务背景

这是一家零售公司，基本的业务逻辑就是进货和卖货。说得好听一点，包含三个要素：商品、销售渠道和供应链。

商品

商品的种类多样，包括居家、服配、快消、数码、运动等。商品的品牌多样，包括自营品牌和第三方品牌。

商品要做研发，比如选品，决定原材料和供应商（工厂）；设计商品和包装；研发生产工艺和流程，以及质量保障。

销售渠道

销售渠道包含线上和线下。

线上渠道包括自有的 APP、官网、小程序等；还有在第三方电商平台的网店（京东店、淘宝店等）。线下渠道包括自营旗舰店、自营门店、合作门店、以及经销商。

供应链

自己有货，就需要存货和发货，这叫 仓储。仓储分为两种，自营仓储和第三方仓储。第三方仓储也称 网仓 或者 云仓，提供入库、出库和存储的一条龙服务。自营仓储就得自己负责这些。

进货要找供应商，要把商品运到仓库；卖货要把商品从仓库打包，要配送到门店或者用户手上，称为 履约。另外，还要处理退换货。从供应到仓储，再到履约，这条链路称为 供应链。

运营

商品、渠道和供应链是业务运转的核心链路。但只有这些是不够的，因为业务需要增长，这种跟业务增长相关的工作称为 运营。

运营可以从用户、商品、事件和玩法的角度来考虑。

用户视角有拉新、促活和促转化；商品视角有促销定价、组合售卖、品类促销；事件视角有营销活动，比如年货节、开门红、开学季；玩法视角有秒杀、限时购、定金购。

财务

上述环节都离不开财务的支持。财务要梳理利润和成本结构，还要给业务的发展提供支持。

零售业务的利润主要是销售利润。成本大致可分成五类：固定成本、采购成本、持有成本、履约成本和资金成本。

此外，公司的运转还需要其他支持部门，比如人事、后勤、行政、品牌、公关、法务等。

以上就是关于业务背景的大致介绍。

业务架构

说完业务背景，我们就得到了业务架构。有人会问，这啥也没做，怎么就有架构了？

前面的描述是对业务的总结和分类，它是描述人对业务的理解。这个理解的过程，就是做架构的思路。

我把业务分为五大核心模块：商品、渠道、供应链、运营和财务。

财务（及相关支持部门）是底座；商品、渠道和供应链是保证业务运转的核心链路；运营（和品牌/市场/公关）是业务起飞的翅膀（见下图）。

当然，你可以有不一样的架构，这个取决于你对业务的理解。

有了这样的业务架构，就可以搭建相关的业务部门，明确工作职能和协作流程，从而让公司的业务运转起来。

技术架构

假设你是公司的技术负责人。现在要搞一套技术体系，有效地支持上述业务。

应该如何设计技术架构？

记住一点，从问题出发。（问题都搞不清楚，做什么架构？）

下面我们来一步步推导出完整的技术架构。

应用层

要卖货得有“门面”。我们的门面是什么？有APP、网页、小程序，还有线下门店。门面要正常运转，需要后台系统来管理用户、商品、库存等。这些支持业务运转的软件统称为 应用。

我们要解决的问题，就是去搭建支持业务运转的应用。

先看懂业务模块，再分清轻重缓急，最后搭建应用。这就是我们先讲业务架构的原因。只有搞清了业务，你才知道轻重缓急，毕竟资源是有限的。

零售业常见的应用如下图所示。

注意到应用之间存在关联，比如“APP” 和“官网”都需要用到登陆、支付和评论等功能。可以把这些通用的能力独立出来，以 网络服务 的形式提供给上层应用（如下图所示）。

互联网时代的软件可以看成服务的集合，其中软件界面和交互能力称为前端，数据和服务称为后端。这就是前后端分离或者服务化的思想。

服务层

服务层实际上是对应用层功能的实现。如何对服务进行抽象，取决于我们对业务的理解。原则是围绕业务的核心链路构建服务。

可以从 “人、货、场”这三个维度来思考（见下图）。

你可能发现有些服务遗漏了，比如注册和登录。其实不必担心，这个架构图不是具体实现，这么做是为了让人理解设计思路。

在实际研发中，有人设计系统，有人设计系统中的模块，有人定义模块的接口，还有人写设计文档，不指望一个架构图搞定所有问题，也没必要把架构图搞得太复杂（记住做架构的目的，是把事情搞简单）。

软件服务化的好处是开发方便，但是大量的服务会带来维护、调试和管理成本的增加。比如，一个应用出了问题，背后可能牵扯上成百上千个服务。要解决这些问题，还要做一些额外的“管理”工作，我们把这些交给 平台层。

平台层

业务的运转需要很多应用，每个应用又对应若干服务，每个服务部署在多台机器上，这就是分布式架构（下图）。

分布式的好处是可以水平扩展，即动态地改变服务和机器数量。但是分布式也引来一系列问题，比如：

• 计算如何保证计算结果的一致性？

• 服务之间如何传递消息？

• 如何让机器的负载均衡？

• 如何追踪服务的调用链路？

• 如何测试系统的整体性能？

为了保障上层的服务稳如泰山，平台层主要提供三种能力：基础能力、服务管理和质量保障。

注意，上图的层次关系是逻辑上的分层，不代表依赖关系。此外，平台层提供的能力可以是服务，也可以是代码框架（中间件）。

数据层

业务越复杂，数据来源越丰富，数据量也越大。这些数据既是业务的基础，又是业务发展的燃料。

数据层面要解决的基本问题是存储、集成和计算。

如图所示，数据的存储采用分布式存储。通过数据集成的能力，把数据归总到 数据仓库。数据仓库可以包含关系数据表、字典表以及图片视频等非结构化数据。

计算引擎覆盖三种常见的计算场景：

离线计算

处理海量数据，辅助业务进行决策，比如销量预测、活动选品，挖掘流失用户。要求数据有深度和广度，但是对实时性要求不高。

实时计算

获取用户实时特征，用于搜索、推荐和广告；或者获取实时的销售数据，在大屏上展示。

在线分析

支持数据分析产品，用于在线的数据分析，例如对订单、库存、利润、成本等各种数据进行聚合和下钻。

设施层

最后是基础设施，包括硬件、操作系统和软件环境。

总结

最后我们做个汇总，为了避免内容太多太杂，再做一些简化（见下图）。

回顾整个过程，我们始终从问题出发，然后一步步去寻找答案。在这个过程中，首先要抓住重点，然后抽象问题，再找解决方案。

需要注意的是，本文展示的架构图，主要体现设计思路，不是软件项目的具体实现。在实际开发中，还要对每个系统进行设计，包括模块和接口的定义，再到类的设计和代码实现。

无论是架构一个组织，还是架构一个模块，其思路是相通的。

思考

前面分析的架构思路，只是我个人的理解，如果你不认同，那一定是我错了，哈哈。

接下来我们再思考几个问题。

1、架构设计的目标是什么？

架构体现的是资源投入，所以目标是让投入产出比最大化。换句话说，要用有限的资源去创造最大的价值。

技术离业务越近，创造的价值越大。如上图所示，应用层和服务层离业务近，平台层、数据层和设施层离业务远。早期的架构设计应该把重点投入在应用层和服务层。

2、架构应该如何演进？

业务的宽度决定了技术的深度。业务变宽，技术就做深；业务变窄，技术就做浅。

“做深”是把非标准化的东西，做成标准化。标准化了就可以做产品，对内降本提效，对外输出赚钱。

“做浅”是把自己不擅长的东西，用别人的东西来替代，典型的例子就是传统企业数据上云。

当然，如果你有技术实力，想反着来也行。先把技术做深，再把业务做宽，用高风险博取高收益。

3、什么是好的架构？

能解决业务问题的架构才是好架构。先看业务的复杂性有没有降低，再看业务的发展有没有向好。不必追求高大上，也别把问题搞复杂。

4、如何架构一个国家？

这个问题很有意思，我偶尔会想一想，但我还没有答案。

5、如何架构自己的人生？

人生不过三万天，你是怎么安排的？比如，你要读多少书？赚多少钱？买多少东西？交什么朋友？看什么风景？……