西西木科技-专业的shopify liquid开发机构-前端JS丨react后端丨API接口丨shopify plus丨外贸独立站
1、为什么要做新闻中心？
这个话题说起来很尴尬。 如今，当很多产品行业人士纷纷宣布需要重新审视中间平台时，在谈论打造新闻中间平台时难免有些羞涩。
但实际上它是又不是。
以阿里巴巴为例。 阿里巴巴之所以拆除中台，是因为中台太大，牵一发而动全身。 如果中间平台自身不能解耦，当业务业态发生变化时就很难解耦。 快速响应业务变化。 目前，阿里巴巴中央平台仍然是阿里巴巴支持天猫、淘宝、聚划算、1688对应其B2C、C2C、C2B、B2B等业务平台的重要载体，包括订单、消息、用户、支付宝等共享中心能力。促销活动。 不仅仍然最大限度地支撑阿里巴巴的全球业务运营，还保留了数千亿的数据资产，为大数据和机器识别技术的发展提供了宝贵的基础。
以茅台为例。 一方面，由于白酒行业线上渗透率较低，严重依赖2C数据资产积累的零售中台无法发力。 另一方面，白酒的重度消费群体多以2B（公司、单位）为主。 ）。 这些不能被简单的在线流程取代。 就线上部分而言，这样的业务业态很难将全球订单和营销追踪的价值最大化。 其中，中台仅起到类似MDM的作用，更不用说在这类传统业务中能够起到快速响应和迭代的作用。
消息平台作为一个相对独立于业务的系统，可以实现以下三点：
开发成本：最大程度完成消息分发系统与业务系统的解耦，最大限度地减少开发资源的浪费和重新发明轮子的问题； 可扩展性：与业务系统单独开发不同，消息中心可以连接各种类消息媒体接口，建立消息模板系统，具有很强的横向扩展性； 适应性强：与营销、促销、订单中台产品需要与业务结合开发三通产品不同，消息中台对各种业务业态的适应性很强。 适应性强，这也是由于其能够只承担业务中的消息分发； 2. 讯息三大要素
说完了新闻平台的价值，我们简单说一下新闻。
1. 消息的性质
大家可以想一想，就像促销系统本质上是变价系统一样，那么消息系统的本质是什么？ 这个问题其实可以通过校准我们日常生活中消息使用场景的固定要素来理解。
以前没有电话的时候，我们都是用信鸽来通讯。 传递信息的人需要把信绑在鸽子腿上，这就是信息的内容。 鸽子知道旅程的目的地和返回地点，这确认了消息的发送对象，也确定了发送者的信息。 鸽子递送本身就是一种媒介。 如果不用鸽子，也可以用马来送信。 这就像选择使用微信或打电话告诉某人他被解雇了一样。 邮件策略是指选择投递方式shopify搭建，如半日投递、次日投递，或者是否需要其他补充邮件方式。
根据上面的描述，我们可以看到，在整个消息分发过程中，从角色上来说，对象只有三个：发送方、媒体方、到达方。
从要素来看：消息内容、消息对象、消息策略。
所以实际上消息分发系统其实只是一个快递系统。 用户想要发送消息，只需在系统中输入消息内容和消息对象，选择消息媒介，设置消息策略（可跳过）即可表达消息。 给指定的联系人。
三、消息中心的复杂性和简单性 1、消息中心的简单性
之前我们讲了消息的三大要素：消息内容、消息对象、消息策略。 事实上，我们发现整个消息分发过程中涉及到的对象看似非常简单，但一个成熟的消息中台产品确实有这么简单的架构。 你起床了吗？
答案显然是否定的。 其实，我们这里可以借用梭罗的一句话：“当我们用教义问答的方式去思考什么是生命的目的设计平台，什么是生命真正的必需品和材料时，人们似乎已经小心翼翼了。如果我们选择这种共同的生活方式而不是任何其他方式。” 比喻我们在产品设计中的一些基本原则，就是我们在做产品设计的时候一定要锚定一些最通用的原则，比如上面提到的消息元素，但是与扩展性相关的功能在设计的时候一定要精心设计。
而这样的产品为什么说是简单呢？
主要有以下几个原因：
系统：产品与业务系统几乎零耦合。 无需与业务系统进行大量数据交互。 用PC来比喻，其实消息中心扮演的是PC的CPU和内存两个PART的角色，甚至INPUT也是消息中心本身扮演的角色。 业务系统只调用消息中心跨境独立站，挥一挥衣袖设计平台；百万级新闻中心设计之道与技巧（上），把所有的浮云都留在这里； 业务：业务层涉及的业务角色较少，需要的功能设计较少。 ，大多都是从上帝的角度或者管理员的角度来设计，完成全流程的功能整合。 当业务角色介入时，只需要封装某些能力就可以基本完全满足需求。 企业的个性化需求。
2. 平台内杂项信息
说完了新闻中心的简单，我们再来说说新闻中心的杂项。
如前所述，其简单性源于功能架构中元素少、角色少、功能少、数据交互少等几大原因。 但在业务和产品架构的设计过程中，我们发现还存在其他的复杂情况。 性的存在：
(1)统一接口
一般的系统设计都需要和业务系统进行耦合，但是我们在设计消息中心产品的时候，从架构之初就确定了它只会负责消息分发的能力，所以它的模型是和业务系统完全解耦的。 类型，这个模式可以这样理解：
从图中可以看出，当业务系统发出请求时，每个请求的渠道和模板都会有异同。 如果接口独立设计，API对接将会存在巨大的隐患。 另一方面，需要设计什么界面？ 一些关键参数也是保持接口一致性的重要保证。
基于以上分析，笔者建议在消息中心建立标准的接口机制设计平台，规范接口的输入参数。 比如我参与的系统会：
这些都放置在界面中。 除了一些基本的认证输入参数外，只保留了两个比较有效的输入参数。
这些都实现了，消息发送的入口点就统一了，接口就可以扩展了，不用做任何改动就可以实现消息通道的横向扩展。
(2)消息模板和组合模板
从逻辑上讲，如果没有消息模板机制，业务系统在调用时需要传递包括完整消息内容在内的所有相关参数。 如果我们把包括通道、内容（变量、文本）、对象等在内的所有东西都打包起来。对于一个包，给它一个ID，以便下次业务系统需要调用它时可以直接使用。
其实这里我们也可以看一下微信的模板消息是如何制作的：
（不过，这里也必须考虑到微信模板消息的特殊性，因为它不是中端架构的产品，所以调用时还是需要传递参数、接收ID等内容。中端系统确实实际上不需要这样设计。）
既然我们已经有了模板的概念，那为什么还需要组合模板呢？ 其实很容易理解。 前面我们讲到的消息模板都是挂在频道下面的，也就是说一个模板只能对应一个频道。 如果出现相同的分发内容，分发对象需要分发两次，那么是不是就意味着业务系统需要调用两个模板呢？ 这样我们就可以将两个模板打包在一起，形成一个新的模板。 这种方式在一些中间平台也称为渠道授权。
(3) 通道和模板：什么是通道？ （业界也有自己的YY名字）
渠道是指业务维度的分布划分，比如营销中心营销渠道、供应链通知渠道等。那么为什么会提出这样的概念呢？ 其实很容易理解。 消息中心是按照前面的讨论来设计的，但是我们会发现一个问题：这么多的消息模板如何管理？
其实很明显，无论我们的消息平台如何解耦，最终都会被赋予业务属性。 我们不妨将这些模板归为一类，将用于某种用途的模板放在这样一个业务渠道下。 这样一个账号就可以挂载多个频道，每个频道还可以覆盖多个模板。 这可以稍后完成。 当开通子账号系统并配置好权限资源树后，就可以实现一一对应，一石二鸟。
(4)功能扩展
（五）技术指标
笔者现在的公司在该业务领域的并发推送和查询水平并不高。 目前，这些风险并不存在。 但是，当消息媒体渠道逐渐扩大、接入系统增多、系统调用频率增加时，就不得不考虑这些问题了。 对于这些即将出现的问题，我们要继续与技术沟通，确定哪些需要异步设计，哪些需要分布式设计，是否需要读写分离。 随着业务的不断丰富，我们会迭代我们的技术框架。
4、新闻平台的困境及解决方案
我将在下一篇文章中讨论这一部分。
西西木科技是shopify官方合作伙伴，通过了Shopify Partner Academy认证，具备多年shopify lic主题开发经验，熟悉Liquid和各项计算机语言。