文章目录
架构调研
本次架构调研主要分为业务架构和技术架构两部分。
一、业务架构
1.单体应用的痛点
在GPF框架诞生前，所有业务都在一个单体应用里承载。每新加一个业务，我们的应用工程就会变得更加的臃肿，软件熵变大，代码难以维护，不少类都有几千行以上。不同的业务代码都杂糅在一个类或者一个方法里。
每承接一个新的业务，我们都要添加很多if else式的打补丁代码。严重违反了开闭原则，这种写法是典型的代码坏味道。当承接的业务越来越多时，系统变的越来越庞大。不管是承接新的业务还是对老的业务进行改动，都越来越麻烦。
这句话对软件工程同样适用。为了解决单体应用架构的痛点:新增业务就给老代码打补丁。实现业务代码给力功能的GPF框架面世。
新架构的核心诉求：业务隔离。更加具体一点，代码隔离，配置文件隔离，运行时流程隔离。围绕业务隔离这个核心诉求，其实我们做了更多的事情，这个后面讲。
2.如何做到业务隔离
我们给每个业务身份建立一个模型，并配一个业务id。业务模型包含这个业务要用到的组件，扩展点，流程配置。所有业务身份构成一个业务身份列表。每个业务模型都有一个业务识别逻辑——当前用户请求是否命中该业务。用户请求进来时，都会走一遍这个路由算法，以确定唯一的业务身份。
唯一的业务身份id确定后，对应的组件集合，扩展点集合，流程配置也就确定了。
1.组件
每个业务的发布页都由十几个到几十个组件构成。这其中有平台通用的组件，比如说商品标题，商品条形码，类目属性，销售属性，sku等全行业都需要的业务组件。垂直业务有垂直业务的定制组件，比如说公益业务有捐赠金额的组件，除了公益业务，其他业务不可能用到这个组件；盒马业务有商品所属门店，管理机构等新零售行业特征的组件。
“业务需要的组件 = 业务定制组件 + 需要的平台通用组件”
2. 扩展点
- 组件扩展点
- 流程扩展点
“业务需要的扩展点 = 业务定制扩展点 + 需要的平台通用扩展点”
3. 隔离方案
通过上述可以发现，平台通用的扩展点和组件是代码复用的！并没有达到之前的代码隔离要求。解决方法也简单：系统初始化时，每个业务身份id都会new一份通用组件和扩展点，并merge自己的定制组件和扩展点。于是，内存里，每个业务身份id都会有一套运行时的独立且完整的组件和扩展点集合。系统真正运行的时候，取到的是组件和扩展点的对象，并不是代码。这样，代码复用，业务数据隔离。这才是最合理的方案。
3.如何做到灵活易接入的中台化产品
仅仅达到业务代码解耦并不够，商品发布系统要做一个中台化的产品。能够快速的支持新业务接入，让新的业务一起共建甚至新业务的同学独立的在GPF框架上接入他们的业务，是我们的目标之一。要做到高扩展，快速接入新业务，这里不得不提到“微内核 + 插件化”技术。
微内核技术：
微内核是内核的一种精简形式。将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入插件
这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计，对系统进行升级，只要用新模块替换旧模块，不需要改变整个操作系统。
微内核技术源于操作系统，但是在互联网产品“平台化”的大浪潮之下，这个技术得到了广泛的应用。
GPF微内核会暴露一系列的SPI(Service Provider Interface)接口，不同的业务按需去实现这些插件接口。系统启动时，程序扫描出所有实现了SPI接口的插件，并集成到系统中对外提供服务。当新业务需要接入时，定义好一个业务身份，同时实现需要的SPI接口，即可完成业务的接入，同时做到业务的隔离。
二、技术架构
主要内容包括 企业总体架构、单个项目架构设计、统一应用分层、调试工具 WinDbg。
1.企业总体架构
当我们有了几百个上千个应用后，不仅仅需要单个项目的架构设计，还需要企业总体架构做顶层思考和指导。大公司与小商贩的商业思维是一样的，但大公司比较难看到商业全貌和本质。而小公司又缺乏客户流量和中间件的应用场景，中型公司则兼而有之，所以企业总体架构也相对好落地。
企业总体架构需要在 技术、业务、管理 之间游刃有余地切换，它包括业务架构、应用架构、数据架构和技术架构。附档是一份脱敏感信息后的真实案例，有参考 TOGAF 标准。但内容以解决公司系统的架构问题为导向、以时间为主线，包括企业商务模型、架构现状、架构规划和架构实施。
2.单个项目架构设计
单个项目的架构设计如同施工图纸，能直接指导工程代码的实施。上一环是功能需求，下一环是代码实施，这是架构设计的价值所在。从功能需求到用例，到用例活动图，到领域图、架构分层，到核心代码，它们之间环环相扣。
做不好领域图可能源自没有做好用例活动图，因为用例活动图是领域图的上一环。关注职责、边界、应用关系、存储、部署是架构设计的核心，下图是具体案例参考。
3.统一应用分层
给应用分层这件事情很简单，但是让一家公司的几百个应用采用统一的分层结构，这可不是件简单的事情。它要做到可大可小、简单易用、支持多种场景，我们使用 IPO 方式：I 表示 Input、O 表示 Output、P 表示 Process，一进一出一处理。应用系统的本质就是机器，是处理设备，也是一进一出一处理，IPO 方式相对于 DDD 而言更为简单实用。
4.调试工具 WinDbg
生产环境偶尔会出现一些异常问题，而 WinDbg 或 GDB 就是解决此类问题的利器。调试工具 WinDbg 如同医生的听诊器，是系统生病时做问题诊断的逆向分析工具，Dump 文件类似于飞机的黑匣子，记录着生产环境程序运行的状态。
主要介绍调试工具 WinDbg 和抓包工具 ProcDump 的使用，并分享一个真实的案例。N 年前不知谁写的代码，导致每一两个月偶尔出现 CPU 飙高的现象。
我们先使用 ProcDump 在生产环境中抓取异常进程的 Dump 文件，然后在不了解代码的情况下通过 WinDbg 命令进行分析，最终定位到有问题的那行代码。
参考：