PowerDotNet平台化软件架构设计与实现系列（03）：系统应用平台

为了复用和解耦，快速开发更多的系统和应用，我们对自己经常说的“系统”和“应用”进行更高级的提取和抽象。

十多年前入行，辗转至今，写过很多很多应用，个人喜欢分门别类整理知识，也看到有些公司这样管理应用（照猫画虎还是挺容易的），所以有个趁手的系统应用管理平台就是顺理成章的事情。现在PowerDotNet就把我自己所理解的系统应用平台最基础最核心的功能做出来，迭代几次后比初始版本加了不少扩展，给系统应用良好运维和管理打下基础。

一、系统

不同的业务部门，我们可以抽象为一个或多个系统，比如金融部门，可以抽象出账户系统、支付系统，财务系统，结算系统，风控系统等。

对于一个完备的电商解决方案，我们能想到的业务系统包括：供应链、库存、生产加工、订单、购物车、支付、财务、结算、票券、虚拟货币、商城、商品、原料、运输、配送、搜索、秒杀、团购、（云）打印、CRM、CTI、活动、消息（含邮件、短信、微信、钉钉）、多媒体、仓库管理、开放平台等。可能用到的最底层的基础设施系统包括：负载均衡、消息队列、分布式缓存、海量文件、企业服务总线ESB、网关、分布式数据库、日志、定时作业、应用升级、代码生成器、数据库管理、数据同步、自动化发布、自动化运维和监控等。我个人实际参与或主导开发过的系统，包括：基础数据、CRM、订单、OA、支付平台、定时任务、网关、应用升级、代码生成器、服务治理、财务、结算、搜索、物流、消息、票券、虚拟货币、MES（生产加工）、WMS（仓库管理）、QMS（质量管理）、TMS（运输管理）、DMS（配送管理）、监控等等，基本上电商领域的资金流、信息流和物流都有涉猎，咩哈哈。好几年前流行的所谓全栈，其实只要多搬几年砖，PC、H5、APP、RF、PAD等形式的应用都写写，后端、前端、客户端、小程序等等都给它覆盖到，外加程序员都爱折腾，各种环境自己负责发布和运维，谁还不是独当一面的多面手呢？

系统的抽象和分解， 非常考验开发人员的架构（业务架构、应用架构、数据架构、技术架构）水平。

二、应用

应用有不同的表现形式，不同的应用类型有不同的关注点。

一般公司的应用都可以分为带界面或者不带界面的，服务或者非服务等等等等，拆分方法不同，关注的应用形态也就不同。

应用的命名也是一门学问，通常要适合自己公司的规范，杂乱无章缺少规划的命名是必须要避免的，关于命名的规范和通用规则本文不再赘述。

2、应用部署管理

我们的应用，最终是要在服务器或者客户端上运行的，运维部署同样是开发需要着重考虑的问题。尤其是DevOps流行以后，可运维便于部署的开发模式肯定更容易被开发人员接受。

支持应用部署心跳健康检查、移入或移除集群等操作：

后续讲到配置中心和服务治理的时候，为了保证应用配置或者API服务的及时性和高可用，可能会按需引入ETCD和Redis等基础组件，当然这些基础组件都是插件化使用的，不是必须，我也提前实现了ETCD和Redis的人工管理（其实ETCD和Redis完全值得我们写出独立的管理平台去运维管理，后续文章我会详细介绍）。

应用部署还需要考虑多数据中心多机房多集群的问题，PowerDotNet在这方面考虑的比较周到，并预留了很多扩展接口，比如下面几个重要基础设施：

（1）、数据中心和集群

集群主要描述了一个集合，一些相似的东西，提供相似的功能，这个就叫做集群。单机处理到达瓶颈的时候，把单机复制几份，这样就构成了一个“集群”。

（2）、服务器

集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。

（3）、域名和负载均衡

上述图片仅列出部分功能效果，供大家参考。

如果系统和应用很多，关系复杂，完全可以独立出一个一级菜单进行应用集群管理。

当然实际的集群管理比我截图复杂的多。

3、应用配置

如果熟悉常见的配置中心，大家都能够猜到配置管理主要是用来做什么的。

PowerDotNet配置中心借鉴了ZooKeeper、Apollo、Nacos等成熟解决方案，并贴近实际开发人员进行了整合创新，通常业务需求应用开发只要点点按钮即可快速搞定。

配合配置中心客户端工具，可以达到配置增删改“实时”生效的效果。

配置文件会在本地磁盘生成一份，每次配置有变更，拉取成功后再保存在本地，这样哪怕配置中心挂了，也不影响应用正常启动和使用。

配置变更的历史都有保存，变更之间能进行diff，支持配置的快速回滚操作。

在分布式环境下，可以追溯各个应用服务器部署实例获取配置的生效状态，便于快速排查定位服务器问题。

PowerDotNet配置中心完美支持对配置的增删改查、推送、回滚、追溯和审计功能。

三、系统分组

一个系统，由一个或多个应用构成。而系统和系统之间，有时候也会有这样那样的联系。

系统间的关系，需要我们继续抽象。于是便有了系统分组概念。比如上面提到的金融部门，可以抽象出账户系统、支付系统，财务系统，结算系统，风控系统等。我们可以把支付、财务、结算、风控等系统归到一个或多个分组里。

再比如某个集团公司业务部门很多，业务逻辑复杂，按主业务拆分后每个业务部门都有独立的CRM、库存、订单、支付、财务、结算等业务系统，系统分组也是必不可少的，有时候甚至需要按照独立公司进行部署，这种情况个人开发多商户平台系统的时候就遇到过，这个多商户平台系统，其实就是支付平台，PowerDotNet系列后续文章会详细介绍，咩哈哈。

四、互联系统

系统和系统之间，不可避免的需要进行数据互联互通。

通常我们通过对外发布RPC接口的形式进行数据交互（特殊情况下也可能进行直接数据库访问，特殊情况有机会再说）。

如果没有系统和应用基础设施的抽象，互联互通会困难重重，自动化运维部署基本无从谈起。

工欲善其事，必先利其器。

系统和应用的提取和抽象，是大中型互联系统解耦的基石，是软件架构设计思想的提升，是程序开发良好组织管理的必要条件，为后续各种中间件、框架或工具的高效组织和使用打下基础。

下一篇介绍PowerDotNet实现的互联系统。