jeffwongishandsome

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

十多年前入行,辗转至今,写过很多很多应用,个人喜欢分门别类整理知识,也看到有些公司这样管理应用(照猫画虎还是挺容易的),所以有个趁手的系统应用管理平台就是顺理成章的事情。现在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实现的互联系统。

相关文章: