专注于Java领域优质技术，接待关注来自： 有赞技术 有赞coder文 | 汤师爷 on 零售一、配景传统模式下，企业的谋划运动会发生大量的业务数据。财政人员需要凭据业务数据，举行会计核算，并输出财政数据。通过这些财政数据，企业可以举行财政治理、财政分析、业务决议。

但会计核算的事情量很是庞大，大多事情也比力基础、简朴，可以被盘算机替代。企业每年在基础的核算事情上会花费大量的人力资源，在更重要的财政治理、财政分析、业务决议上无暇顾及。

为相识决此类问题，财政中台应运而生。财政中台是业务系统和财政总账系统间的桥梁，通过搜集所有业务数据，举行筛选、核算、转换，自动生成财政数据，并传入财政总账系统，节约大量会计核算的人工成本。除此之外，财政人员不需要在各个业务系统间往返切换，核对业务数据。财政中台汇聚了所有财政数据，财政人员可以在统一的事情台上举行数据核对和会计事情，不需要跨多个系统操作。

通过财政中台，可以轻松实现业财一体化，财政人员可以解放生产力，产出更高的价值。二、财政中台业务架构2.1 零售整体业务架构零售整体业务架构分为前台业务、总部中台、企业/业务后台。前台业务的特点是变化快、差异性大、细节体验、跨平台、多触点。

前台业务资助商家整合尽可能多的零售渠道举行销售，以满足主顾购物、娱乐和社交的综合体验需求。总部中台从架构上是串联前台业务和后台业务，基于零售商家的焦点谋划场景，建设会员、生意业务、营销、运营、财政、数据等焦点功效。

总部中台并不直接为商家和消费者提供应用服务，它的主要职责是汇总所有业务数据，协同各个业务单元，提炼业务的共性需求，支撑前、后台业务的快速生长。通过总部中台，商家可以跟踪和积累消费者的购物全渠道、全历程的数据，在这个历程中与消费者实时互动，掌握消费者在购置历程中的决议变化，给消费者个性化建议，提升购物体验。

再依靠大数据，对用户做到精准营销、智能推荐商品；智能化采购更适合销售的产物；做好财政治理，连续提升资金使用效率。企业/业务后台包罗采购要货、供应链、原质料管控、生产制造、条约治理、加盟署理、财政总账等基础业务。

部门业务可能由商家的ERP系统完成，所以总部中台和ERP系统会做好数据对接，商家的ERP系统仍然可以继续使用。财政中台属于总部中台的一部门，财政中台通过搜集所有业务数据，举行筛选、核算、转换，自动生成财政数据。

同时，财政中台提炼出财政相关的共性服务，支撑前、后台业务的快速生长，资助商家做好财政治理、财政分析和业务决议。2.2 财政中台业务架构财政中台搜集全渠道销售、供应链、资产、营销推广等数据，自动完成会计核算，生成相应的财政数据。同时，财政中台可以进一步对接企业的财政总账；为其他系统集成提供尺度化的开放能力；为互助同伴提供用度对账等服务；为数据报表提供原始数据，加工出财政报表，为财政分析、业务决议提供有力的支持。

三、财政中台应用架构3.1 什么是应用架构？应用架构界说了系统由哪些逻辑模块组成，以及逻辑模块之间的关系，也称之为逻辑架构图。应用架构起到承上启下的作用，一方面承接业务架构的落地，一方面影响技术选型。3.2 如何设计应用架构？设计应用架构，首先要明确设计的粒度和条理，在差别粒度和条理，关注点是纷歧样的。

务异常庞大，对于这种庞大业务，尤其要从宏观到微观逐层举行详细的分析和设计，保证整体架构的有序性和一致性。如果不这样做，很容易让产物技术团队陷入杂乱中，进而极大降低团队的相同和协作效率。这里可以联合 Simon Brown 提出的 C4 模型来思量设计元素的粒度和条理。自上而下，Simon Brown 将整个软件系统分为了四个条理，划分为系统上下文（System Context）、容器（Containers）、组件（Components）以及类（Classes），这些条理的说明如下所示。

系统上下文：是最高的抽象条理，代表了能够提供业务价值的构件。一个系统由多个独立的容器组成。

容器：是指一个在其内部可以执行组件或驻留数据的构件。作为整个系统的一部门，容器通常是可执行文件，但未必是各自独立的历程。组件：可以想象成一个或多个类组成的逻辑群组。

组件通常由多个类在更高条理的约束下组合而成。类：在一个面向工具的世界里，类是软件系统的最小结构单元。3.3 财政中台应用架构设计那么，财政中台系统在上述四个条理划分该如何设计？3.3.1 系统上下文条理设计首先是系统上下文条理，该条理会重点关注要设计的系统和其他系统之间的关系。

财政中台系统上下文的设计如下图所示。3.3.2 容器条理设计其次是容器条理，该条理会将整个系统放大，关注系统内部由哪些容器组成，容器基本等同于限界上下文的观点。

限界上下文的划分是 DDD 战略设计中的一部门，而且是最焦点的设计事情，需要在该条理识别出限界上下文，这会对后续微服务架构落地起到关键性作用。上图为财政中台系统内应用架构图，接纳分层架构模式，图里的应用层、领域层、基础设施层和DDD中的观点一致，但它们是容器条理下的分层逻辑，视角是整个系统内。

对于单体系统来说，应用层和领域层逻辑会比力简朴，通常汇合并为一个微服务部署，内部也不会有很是清晰的限界上下文划分。但对于企业级系统，业务逻辑很是庞大，内部会划分出众多职责单一、功效完整的限界上下文，以保证系统架构康健、有序地举行演进。应用层：应用层是很薄的一层，应用层内的服务对应一个具有业务价值的业务用例。

它主要卖力对领域服务举行组合和编排，卖力处置惩罚业务用例内的执行顺序以及效果的组装，通过API网关向接入层提供服务。容器级应用层涉及整个系统的逻辑，通常包罗多个廉价的限界上下文，它们的内部业务逻辑不会很庞大，但因为直接面向用户，为了应对快速变化的外部需求，应用层变更会很是频繁，它通过领域服务的组合和编排实现业务流程的快速适配上线。

例如：上图所示的结算治理是一个应用层限界上下文，它为接入层提供与结算治理相关的应用服务，它通过组合、编排领域层的核算域、结算域、收付域以及其他业务系统的领域服务，来实现自身应用服务能力。领域层：领域层是很厚的一层，它是业务软件的焦点所在，包罗了本事域所涉及的领域工具、领域服务以及它们之间的关系，卖力表达业务观点、业务状态信息以及业务规则。领域驱动设计提倡富领域模型，即只管将业务逻辑归属到领域工具上，实在无法归属的部门则以领域服务的形式举行界说。

用户的需求经常变化，但变化总是有纪律的，用户体验、操作习惯、市场情况以及治理流程的变化，往往会导致界面逻辑、应用逻辑变化，但焦点领域逻辑不会有太大变化，所以领域层的业务逻辑通常是共性的、稳定的。容器级领域层涉及整个系统的逻辑，通常包罗多个限界上下文，它们为整体系统的微服务拆分提供依据。基础设施层：它向其他层提供通用的技术能力，例如：漫衍式通信能力、持久化能力、消息通信能力、任务调理能力等。

3.3.3 组件条理设计再次是组件条理，该条理会将单个容器放大，组件是由一个或多个类组成的逻辑组，配合完成一类职责。在该条理会关注容器内部是如何分层的，每层包罗哪些逻辑组件。上图为应用层容器架构，同样接纳分层架构，包罗接口层、应用层、防腐层、基础设施层。

接口层界说了提供应上层使用的服务协议（API），接口层的使用方通常是展现层。这里的应用层是更细粒度的、容器内的条理，或者说是战术级此外条理，凭据庞大度差别，它通常包罗一到多个限界上下文的应用服务和业务组件，每个应用服务通过编排其他限界上下文的服务，实现业务场景或业务用例。防腐层用于和其他限界上下文集成，在防腐层内部，你可以将自己的模型和外部模型举行转换，防止受外部模型污染，进而让内部逻辑不稳定。当外部模型或接口协议发生变化时，只需要修改防腐层逻辑，不会影响到自身业务逻辑。

应用层容器内通常没有领域模型，因此也不需要会见数据库，因为它内部主要是组合、编排的逻辑，如果泛起类似领域模型的观点，要分析是不是有部门领域逻辑外泄到应用层，并思量将领域逻辑下沉到领域层，以保证应用层的职责统一。上图为领域层容器架构，分为接口层、应用层、领域层、防腐层、基础设施层。接口层界说了提供应上层使用的服务协议（API），接口层的使用方通常是应用层容器。应用层通过编排领域层的领域服务、领域模型以及少量外部服务来对外提供服务能力，这里强调少量的外部服务，是因为领域层容器内部的业务逻辑通常是共性的、稳定的，它只会依赖比它更基础、更稳定的服务能力，而且依赖外部服务要尽可能少，这样才气保证容器内部的业务逻辑是共性的、稳定的。

这里的领域层是更细粒度的、容器内的条理，或者说是战术级此外条理。领域层包罗种种领域模型，例如：领域实体、聚合根、领域服务、仓储等。仓储作为领域层和基础设施层的毗连组件，使得领域层不必过多的关注存储细节。在设计时，将仓储接口放在领域层，而将仓储的详细实现放在基础设施层，领域层通过接口会见数据存储，而不必过多的关注仓储存储数据的细节，这样使得领域层将更多的关注点放在领域逻辑上面。

领域层容器架构最焦点的是领域层，它包罗焦点的业务模型和业务逻辑，它与详细的技术框架无关，只专注于业务自己，领域层是沉淀领域知识的地方，是业务人员和技术人员相同的基础和桥梁。3.3.4 类条理设计最后是类条理，类是系统构建的最小模块，该条理关注组件里详细要设计哪些类，每个类的职责是什么，类与类之间的关系是怎样的，类条理偏细节，这里就不详细展开。四、微服务架构设计微服务架构，是一种技术架构方式。

它将应用构建成一系列按业务领域划分的、小的自治服务。微服务被认为是未来的偏向，通过将应用和服务剖析成更小的、松散耦合的组件，它们可以越发容易升级和扩展。

越来越多的互联网公司使用这种架构来部署自己的系统，有赞也不破例。微服务架构有许多的利益：将庞大单体应用拆分为多个微服务来解决庞大性问题。每个微服务可以由专门的团队来开发维护。每个微服务可以独立部署、独立扩展。

微服务架构也有许多不足：微服务架构是漫衍式架构，会带来漫衍式架构固有的庞大性。数据库分区带来的数据一致性问题。

测试一个基于微服务架构的应用系统变得很是贫苦。微服务架构实际上更多是技术实现和运维部署的领域，究竟如何拆分微服务，微服务架构给不出谜底。这就要用到应用架构的设计效果，上文中说到容器基本等同于限界上下文的观点，限界上下文的划分对指导微服务拆分有很是重要作用。

一个微服务一般包罗一到多个限界上下文，如何界定微服务需要包罗几个限界上下文？一是会凭据限界上下文的业务庞大度来判断，如果庞大度很是高，而且由多名开发人员维护，一般会单独部署为一个微服务，独立演进。二是会凭据技术庞大度来判断，好比该业务域存在高并发、高可用、性能要求苛刻的场景，需要接纳特殊的技术架构，通常也会思量单独部署，与其他限界上下文在物理上隔脱离。

微服务架构需要遵循逐步演进的原则，多个限界上下文一开始通常部署在一个微服务中，随着业务庞大度和技术庞大度上升，再逐步拆分为多个微服务。一开始就把微服务拆分得很细，会带来大量漫衍式架构的固有问题，可能业务还没生长起来，就被漫衍式的问题搞得焦头烂额。下面先容一下财政中台的微服务架构是如何演化。一开始业务比力简朴，为了利便部署维护，如上图所示，所有限界上下文会部署到一个微服务中对外提供服务，但很快会遇到问题，业务越来越庞大，会与其他系统发生依赖关系。

例如：供应链系统的进销存场景会触发达务中台的核算业务，财政中台需要依赖供应链系统的库存票据举行核算，供应链的某些场景也需要依赖财政中台的能力，进而会发生部署上的循环依赖，当某个项目双方相互依赖时，公布时就泛起无法确定公布顺序的难题，强行公布会导致公布期间一段时间内部门功效不行用，不能平滑过渡。为相识决不能平滑公布的问题，可以将应用层和领域层举行物理隔离，离开部署。

拿供应链系统和财政中台系统举例，从业务定位来看，供应链是财政中台的上游业务，供应链的焦点业务逻辑是完全不依赖财政业务的，因此供应链领域层的限界上下文是不会依赖财政中台领域层的限界上下文。但某些应用场景，供应链的应用层需要编排财政中台的数据给用户展示，或触发达务中台的业务执行，这时，只需要供应链的应用层依赖财政中台的领域层就行。所以，公布顺序根据1、2、3、4的顺序公布，就不会再泛起部署上循环依赖的问题。随着业务量发作，差别限界上下文面临的会见量级是纷歧样的，例如：核算域需要处置惩罚高并发量的业务票据核算，需要解决高并发、高性能等的技术问题，所以核算域会单独分散出来，部署为微服务，这样就可以独立设计和水平扩展。

但有些限界上下文只管能部署在一起，例如结算域和票据明细域，因为一旦离开部署，会发生漫衍式事务问题，这会很是棘手，现实场景也遇到过微服务拆分后，漫衍式事务问题一直没能很好解决，又把微服务合并了。所以如果不是遇到业务庞大渡过高、高可用、高并发、高性能等问题，只管不要把微服务拆分得很细，防止泛起业务未生长起来，反而带来一堆漫衍式架构固有的庞大性问题。五、中台、DDD与微服务中台的界说泉源于阿里的中台战略（详见《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》钟华编著），中台的本质是提炼各个业务线的共性需求，并将这些功效打造成组件化的产物。

前台要做什么业务，需要什么资源可以直接找中台，不需要每次去改动自己的底层，而是在更富厚、灵活的“大中台”基础上获取业务能力支持，让“小前台”越发灵活敏捷，中台架构被认为是未来企业级架构的偏向。中台、DDD 以及微服务属于差别层面的内容，中台架构是一种企业级的架构模式，是从企业全局、整体视角来看的架构全貌。DDD 是一套处置惩罚庞大业务的设计思想，内里的应用层、领域层、应用服务、领域服务和中台里许多观点一脉相承。

微服务是技术实现和部署的领域，它是落地中台架构的技术工具。一张图来表达他们之间的关系：六、总结本文通过有赞零售财政中台架构的实践，详细先容了庞大业务系统的架构历程，首先基于整体业务架构，设计出系统的应用架构，应用架构有差别的设计粒度，可以参考 C4 模型从宏观视角到微观视角，逐步开展设计事情。

接着，基于应用架构的限界上下文的划分，可以指导我们举行微服务的拆分，通过对限界上下文庞大度的判断，确定划分为几个微服务较为合适。最后先容了中台、DDD 与微服务之间的关系。

通过这篇文章，希望能为开发者在架构设计上提供一些参考价值。现在人工智能很是火爆，许多朋侪都想学，可是一般的教程都是为博硕生准备的，太难看懂了。

最近发现了一个很是适合小白入门的教程，不仅通俗易懂而且还很滑稽诙谐。所以忍不住分享一下给大家。点这里可以跳转到教程。

https://www.captainbed.net/suga。

本文来源：米6体育官网app下载手机端-www.rundafeng.com