系统架构总览
系统架构总览
本文档的目标为帮助读者对 Ticos 的整体架构有一个总体性的认知，从而对于如何更好的应用本产品体系来提升自己的工作产生更加的效果。
系统边界
一个系统架构的成功前提是让其做足够少的事情，因此需要尽早明确系统的边界。Ticos 的目标为以一个自洽体系为智能硬件设备的研发提供高效支撑，并有效治理设备数据。
- 关注目标为智能化产品，也即自身会持续产生设备数据的带电子属性的各类设备；
- 关注阶段为产品的研发和围绕自身产生数据的运营体系；
- 具备高度自洽性，可独立运行和使用。除了支持开发外，客户群体也可以使用 Ticos 来完成基本的运营工作；
- 具备必要的开放性，可以整合其他的系统数据，也可以被整合到其他的系统中；
以上边界描述中最需要注意的是在自洽性和开放性之间的均衡。为了可自洽运行所实现的功能应该遵循最小原则，不应无限制的持续侵入到其他专业系统的领地，以免造成协同上的不自然。
场景抽象
对于所有的物联网场景，我们可以大体抽象如下的几种：
单设备单应用。此类通常是消费电子的场景，比如消费者购买了一个蓝牙音箱，再安装一个对应的手机应用，就可以正常使用了。不需要整合其他的运营系统，也不需要和其他的设备协同（除了蓝牙连接这个基本功能）。
多设备单场景。智能家居就是一个典型的多设备单场景示例。一个家庭里通常会有多个智能设备，比如智能门铃、安防摄像头、照明等。消费者会使用一个手机应用对这些设备进行统一管理，且可以对设备之间进行关联，比如在窗户的红外报警触发时，让安防摄像头进行对应的拍照。
多层多设备协同。连锁店管理很符合这种场景，其他也有很多类似场景，比如集团公司的办公室管理等。在这种场景里，设备会被按照地理位置或者其他规则进行分组，同一组内的设备可以直接协同，不同组之间的设备会上报到同一个上层设备。
多设备多层次多系统。这是最复杂的工业场景，比如工厂管理等，除了类似上述的多层多设备协同外，还需要整合其他的各种系统，如 ERP 系统、生产过程管理系统等，因此还需要进行数据的打通并在必要时下发设备的控制指令。
作为一个通用的物联低代码底座，我们需要对以上的场景都提供支持能力，因此需要进行合理的架构分层，而且不应为了支持复杂场景而导致对简单场景的支持产生极大的额外负担。
我们可以将设备的管理层次抽象为如下所示的简单模型：
整个体系只有两个概念：设备组、设备。每个设备组可以同时包含若干个设备和若干个子设备组，每一个设备组可以包含额外的灵活可定义的描述信息，以对应到一个物理结构（如地理位置）或者对应到一个逻辑结构（如质量管理）。根节点可以认为只是一种没有父节点的设备组。
关键角色
终端用户。终端用户可能是消费者，也可能是专业领域的执行者，比如产线工人等。这些用户会根据产品的使用说明书尽可能规范的使用产品，但不能对他们的专业性和纪律性作过高的假设。
开发者，可以简单分为如下数种类型：
- 硬件产品开发。这类人员致力于创造智能化硬件产品，开发在硬件端运行的嵌入式软件，并将设备接入到云服务。
- 运营开发。这类开发人员通常面向各种 Web 应用和移动应用。这些应用的本质是查看和分析各类设备数据，以及对设备进行配置管理。
- 服务端开发与运维。这类开发人员专注于各类后端在线服务的开发和运维，重心在服务的稳定性和在尽可能不影响正常使用的情况下平滑升级。
用户运营，指产品上线后各种围绕提升用户满意度的工作，最主要是如下几种：
- 售后客服，通过售后的回答使用过程中的问题，以及产品遇到质量问题时提供对应的解决方案，比如免费退换货等；
- 进行数据分析，以用户画像的方式持续定位产品的优缺点和用户的总体反馈，从而为优化产品开发和提升销售额做出重要的建议；
- 财务相关人员（通常也包含公司负责人），进行财务数据的审计以及相关财务操作；
渠道合作伙伴。销售渠道并不是产品的使用者，他们负责将产品进行更大范围的传播，从而提升产品的销售额，渠道的主要商业模式为依赖于产品的销售额而进行利润分成，或者以自由定价方式而赚取其中的差价（当然也可能因为需要清库存而产生亏损）。
原则上渠道的管理不属于系统的边界内事务，应在独立的一套系统中进行管理。但从系统的角度应提供必要的渠道相关支撑数据（提供对应的 API）。
技术合作伙伴。本质上也是一种开发者，只是从属于不同的组织。他们会向平台递交技术组件、应用模板等共享数字资产，通过共同繁荣社区以从中获取传播机会和商业化机会。
以上角色的核心诉求需要能够在系统内得到满足。
系统的基本构成
统一账号体系
统一的账号体系提供一致的账号管理体验。
基础云服务
基础云服务提供关键的几项能力：
- 设备接入和数据上传；
- 数据存储；
- 数据和指令下发；
- 通过云函数机制提供业务级 API 的扩展机制；
- 通过 API 转调的方式集中管理现有的第三方技术服务（如各种视觉识别服务等）；
低代码开发支撑服务
低代码开发包括产品开发和运营开发。平台需要为这些开发工具链提供对应的代码工程管理服务。
低代码引擎
低代码开发过程所产生的结果需要相应的运行时引擎才能正确运转。同上所述，低代码引擎也包含面向产品运行场景和运营场景这两种。产品场景的低代码引擎是一个软件系统，而运营场景的低代码引擎则是一个在线服务。
开放市场
本质上开放市场的开放只是一种商业策略，在架构层面这是开发和运营过程中的可重用数字资产的统一管理服务。通过对生态系统的加强，来加速可重用数字资产库的丰富过程，而只有数字资产库的极大丰富才能真正简化产品和运营系统的开发过程，达到低代码甚至无代码的效果。
以上子系统在业务体系中的结构和关联关系可以总结为如下图表：
物模型驱动开发
低代码开发的核心理念是模型驱动，而物联低代码开发的核心理念是物模型驱动。
物模型本质上只是对设备和模组能力的一种描述方式。比如下列就是对一种智能水杯能力描述的一个示范：
这种能力描述我们通常会以 JSON 的方式描述（之前的 SOA 时代也曾流行用 XML），并在各个子系统中以不同的编程语言使用该 JSON 描述，来达成数据驱动的系统连接效果。有一些子系统会以动态的方式在运行时解析该 JSON 数据，而有些更强调运行性能的领域则会考虑预先基于 JSON 描述生成静态的代码，比如在系统开发领域就会经常见到这样的开发模型。
我们需要解决的挑战如下：
- 如何以一种通用可扩展的方式描述所有的设备能力和对应的数据描述，关键在于如何能描述未来才会出现的设备能力；
- 如何进行协议的版本管理，从而进行最大可能的向前和向后兼容；
- 如何设计自动治理的系统架构，使能及时发现因为开发和运维人员的疏忽导致的系统不一致问题，且在不一致时能尽可能自我维持而不是任其崩溃；
- 作为一个 24x7 运行的云服务，在系统升级时需要支持灰度发布和回滚机制，这个过程不应导致系统整体离线；
一种良好的协议驱动模式可以最大程度上降低对系统稳定性的影响。我们的系统架构对应到的数据驱动如下所示：
当然，每一层的 Schema 都需要相应的多语言管理机制。这种协议驱动开发的典型案例是 Google ProtoBuf，我们需要在协议层面再进一步，形成运行时引擎，以免在协议改变时虽然不需要手动修改 API，但仍然不得不手动去修改业务代码的问题。
系统的演进路线
一种良好设计的核心架构可以相对稳定的存在比较长的时间，但不代表着系统架构师们可以高枕无忧。业务场景和产业链的变化，竞争态势的变化都会导致用户对于系统的期望会持续变化。系统需要在保持理念和核心架构稳定的前提下，与时俱进，持续迭代自身以满足目标用户的性能和功能需求。
就目前可前瞻的角度，我们的系统需要沿如下几点进行演进：
- 平台和标准兼容性。不同的标准可能对于系统的互操作方式产生极大的影响，比如 BLE （低功耗蓝牙）协议相比我们传统开发时使用的网络协议就增加了非常多的限制，未来必然会继续出现各种类似的限制，而系统必须要这种种限制下仍然能够正常运行，且应尽可能限制新协议和标准的影响范围；
- 性能需求。我们通常可以用脚本驱动加数据驱动的方式来解耦我们的子系统，但这样的设计前提是系统对于性能的不敏感性。一旦提升到比较敏感的地步（而这在物联网场景是很常见的问题），就需要抛弃脚本和数据驱动，改用系统级静态编码的方式满足性能需求。在这种压力下如何能够保持架构原则不开倒车，就需要相对精细的策略，比如简单易用且自动化程度够高的代码生成和更新机制；
- 系统规模。系统规模包括数据存储规模和同时服务规模。在规模增长的同时必然会涉及到系统架构的持续升级问题。我们在设计之初已经尽可能用云原生的原则将规模复杂性剥离出去，从而在规模提升时做到可通过独立升级对应的云原生基础设施达到自然的服务能力升级效果。但是这显然不能一概而论；
- 复杂需求。这是比较难以预测的场景。总体上的原则是比客户尽可能提前想一步，从而避免在客户提出需求后才发现系统无法满足，导致整体的交付周期延长到难以想象的长度。不过正确的应对策略是本文一开始就强调的系统边界原则，用分层原则将不应该由核心系统统一支撑的边缘需求剥离为一个定制化的子系统和应用。必要时我们需要通过增加系统的层次来在定制性和通用性之间找到一个合理的均衡点；
随着系统的持续演进，本文档也需要及时的进行更新。