框架总体原则：大中台小前台框架的思考
业务中台采用领域驱动设计(DDD )，在此基础上构建业务能力SAAS，持续反复演进。
平台化定位进行了业务隔离设计，与一系列支持不同玩法业务类型的系统进行了易于定制的扩展。
前后分离，通过服务器接入层进行路由自适应转发。
支持天然存储库表、消息去耦和分布式缓存设计、灵活的扩展，支持大数据并行方案。
系统逻辑结构图：
接下来介绍各自的部分。
ecececececececection : ECECENTER平台层通过流程编排类技术手段，构建基础能力作为业务解决方案，将共性和个性化问题以交易设计为例说明这一分层理念。 通过深入分析电子商务业务
可以确认几乎所有的交易都涉及下图的所有领域(库存、优惠、价格…)，但是从每个领域来看，玩法几乎没有变化。 将这些域的基础能力完全沉淀以形成原子的基础能力，通过扩展点的方式应对未来特殊场景的个性化扩展。
平台层为了应对各种交易场景(一口价、拍卖、货款兑换、预售……)，将原子的基础能力组装成满足各种场景的解决方案，明确了作为服务。
服务访问层：服务访问层是连接前端产品和中端产品层的纽带，实质上是以前的web APP。 不同的是，现在的前后端分离后，只包含java代码，使用springBoot web。 进行参数转换，路由分发，调用中台服务器，封装结果。 它跨越了前后端交互规范、请求路由映射规范、web工程目录结构、负载均衡方案、问题和安全问题，
在后续主题中详细介绍这个。
公共基础组件(沉淀和抽象公共独立的公共基础组件)。 这些组件在服务于本项目、本团队的同时，还可以开源服务于更多的人。 提取几个非常重要的组件并说明其目的。
数据访问组件：抽象封装分区表访问、读写隔离、初步切换。
消息中间件组件：这个选择非常多，对于开源的，有activeMQ、RabbitMQ、RocketMQ、Kafka等等。 此外，由AlibabaCloud (阿里巴巴云)、AWS、腾云等提供，支持的云版本也非常多。 如果不创建此包，而是透明地处理其上的APP应用程序，则后期进行此调整将非常痛苦。 特别是这一套
地址库组件：在需要扩大国际市场时，统一地理地址相关服务非常重要，不同文化背景的国家这种差异非常大，国内也涉及三级、四级、五级地址问题
如果云服务的容器分层技术团队不是很大，也没有运输技术人员，我们建议直接使用成熟的ECS和其他云服务，比如阿里巴巴云，而不是购买物理机自己构建环境这样，您就可以节省大量时间和时间，专心开发业务产品，同时使用docker容器部署APP应用程序，所需的计算机数量较少，部署起来非常方便、高效。
业务前端产品： ios、安卓app、H5 APP、PC网站、微信支付宝(Alipay )小程序属于这一层，前端产品主要基于业务形态和产品定位构建。 在电子商务方面，主要指移动APP、H5商城、PC商城、小程序商城。 以小程序为例进行说明。
为了应对小程序，有社交电子公司这样的热点，也有这样优秀的电子商务系统，所以不做什么优秀的电子商务客户的前台产品是不可能的。 为此，为了打破脑筋，我们把电子商务和礼品结合起来制定了“礼尚往来”的小程序。 以下是产品的截图。
稳定和安全保障系统相对于电商系统这样的网络交易系统，流量会因运营活动而波动非常大，特别是到了双11这样的大活动，流量峰值会达到平时的几十~几百倍，有些接口甚至更低核心系统的系统指标、流量、接口调用量和rt以及流量限制和异常的监视非常重要。 几年前，只有BAT的几家大公司有能力在这方面做好。 通过参与这样大规模的活动推动技术进步，并将开源社区和几个大工厂类似的计划回馈给开源社区，目前小技术团队制作这个并不是一件难事。 这里简单介绍一下使用的框架。 有关详细信息，请参阅官方文档。
sentinel:是一种面向分布式服务体系结构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务稳定性。 该系统经过阿里内部双11年多的验证，稳定性和可靠性非常好，最近开放了。
dubbokeeper: dubbo官方监控dubbo-monitor-simple性能非常差，经常被卡住。 经过对几种成熟框架的比较，最终确定使用dubbokeeper. dubbokeeper社区版dubboadmin，包括APP管理、动态配置、动态配置
pinpoint:目前基于微服务架构，从用户开始到响应，中间呼叫链路很长，一般要跨越几十个系统，路径非常多，不需要工具就可以找到很花时间的响应像Pinpoint这样的工具就是为了解决这个问题而出现的，Pinpoint的优点是代码为零
侵入，运用JavaAgent字节码增强技术，追踪每个请求的完整调用链路。Telegraf+ influxDB+ Grafana：主要用来实现业务数据的实时监控方案，如交易额的不正常波动，订单量的突然下跌等。Telegraf 是收集数据的代理程序，可以根据业务需要添加插件扩展服务，收集到的数据写入分布式时序数据库influxDB,再通过grafana 可视化的展示出来。
工程结构：逻辑结构映射到物理的工程结构，每个逻辑单元对应为一个子工程，如果是用idea 开发，就是一个model, 当然model 里边会有子model；至于需要打包构建多少个系统其决定性因素是你团队的规模，如果团队规模较少，中台系统合并到3-4个左右就足够了，如果团非常大，一个团队负责一个业务板块的，并为其构建多个系统，也是非常正常的，像较大的电商公司，负责商品的就是一个团队，商品相关的系统就有数10个。以交易为例，可以将交易的系统合并为一个系统，但在工程的组织结构上是对立的，方便将来的拆分。
这次先介绍这些整体框架，后面还会有陆续的文章推出，按照每个部分一到多个专题介绍核心设计。对这块有兴趣的欢迎交流技术方案和产品玩法。
更多文章欢迎访问 http://www.apexyun.com/
公众号:银河系1号
联系邮箱：public@space-explore.com
(未经同意，请勿转载)