营养系统相关

设计模式

用户信息及人脸特征值下发

• 观察者模式(Observer)

  联动。订阅发布模式。定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知，并自动更新。Excel的单元格计算….呵呵。触发器的思想

疾病与营养分析、推荐的关系

• 策略模式(Strategy)

  多文案切换。定义一系列的算法，把它们一个个封装起来，并且使它们之间可以互相替换，从而让算法可以独立于使用它们的用户而变化。商场的促销规则，根据用户的性质，花费等计算优惠方法的选择。

数据库访问

代理模式?

论文

• 2019年3月，我所在公司立项并研发了自助就餐及营养健康分析系统的项目。该项目包括软件、硬件两大组成部分。其中，软件SAAS平台部分用于收集分析就餐数据，并采集用户健康数据，给出就餐建议及营养分析。硬件部分用于记录用户取餐的菜品名、重量,并上传至SAAS平台。我在其中担任系统架构师，负责整个项目的架构设计，以及软硬件团队的管理工作。在项目的设计中，为了提高系统的稳定性及解耦各模块，以及提高系统的并发度，主要采用了以下几种设计模式。1、为了解耦软件与硬件之间的交互，采用了观察者模式，方便将平台的数据实时下发到相关的设备上。2、使用了策略模式，定义了不同疾病所摄入的营养及运动，根据通过医疗系统获取到用户的健康情况，进行营养指导及干预，为营养师更进一步的工作提供指导。3、为了提供系统的并发，由于数据库层是并发的瓶颈，我们采用了代理模式对数据库进行分表分库，提高了数据库层面的容量及并发。该项目开发历时10个月，于2020年初上线，至今已上线近一百多家单位，稳定性得到了实践的验证。

• 软件设计模式是一套被反复使用的、经过分类编目的代码设计经验的总结。使用设计模式是为了重用代码以提高编码效率、增加代码的可理解性、保证代码的可靠性。软件设计模式是软件开发中的最佳实践之一，它经常被软件开发人员在面向对象软件开发过程中所采用。

• 软件设计模式主要有三大类：创建型、结构型、行为型。其中创建型主要用于创建新的对象，主要包含：工厂模式、抽象工厂模式、原型模式、单例模式、构建器模式。结构型主要用于创建更大更有序的结构，主要包括：适配器模式，桥接模式，组合模式，代理模式，装饰模式，外观模式，享元模式等。行为型主要用于不同类之间的交互及职责，具体包括：观察者模式、职责链模式，命令模式，解释器模式，中介者模式，备忘录模式等。

• 在自助就餐及营养健康分析系统的架构设计过程中，由于每个项目，智能硬件终端是部署在各个食堂的，实际运行过程中有几百上各个食堂，每个食堂平均有三十来台自助设备，这样算下来，有几万台设备与服务器进行交互。为了减少项目对网络的依赖，需要将用户数据，和用户人脸特征值下发到各台设备，我们采用了观察者模式，通过mqtt broker,然后自己实现了mqtt服务端与mqtt客户端的逻辑，其中mqtt服务端，发布用户信息、用户特征值、基础配置等主题信息，所有主题均通过mqtt broker进行转发。mqtt客户端根据设备类型配置定阅不同的主题，例如一般自助设备终端订阅用户信息就可以，具有人脸识别功能的客户端，在评阅用户信息的同时，也订阅用户人脸特征值信息，这样实现了人脸1：N的对比在本地实现。经过使用观察者模式，将新增/修改/删除的信息实时同步到各台设备，解耦了设备对互联网及SASS平台的依赖，也就是说断网不影响用户就餐，增强整个系统的稳定性。

• 在自助就餐及营养健康分析系统的架构设计过程中，产品经理经过调研SAAS平台端的营养分析模块功能中，有针对不同的疾病，对三十多种营养元素进行设置，同时对该疾病的饮食禁忌都有不同的算法。为了针对该需求实现功能，可以采用if else来判断，但是这种设计扩展性差，也不符合设计模式中的开闭原则。我们采用了，策略模式，根据依赖倒置原则，我们需要一个接口CommonNutrStrategy。根据一职责原则，我们分别为每种常见疾病提供一个个具体实现类，例如FateNutrStrategy，实现了接口CommonNutrStrategy。这样，当系统增加了一种新的疾病算法时，只需要提供具体的算法实现类，就可以无缝对接到平台。让疾病的算法独立于用户。当用户的相关属性（疾病、BMI值等）有更新时，系统会自动根据相关算法进行推荐，同时根据智能硬件传上来的数据，进行进一步匹配分析，给出每餐、每日的营养报告。

• 在自助就餐及营养健康分析系统的架构设计过程中，我们考虑到该系统是以SAAS平台提供服务，要考虑到并发性能，在WEB设计开始中，服务端可以通过负载均衡来增加后端服务器实现性能的提升。一般的WEB性能瓶颈是数据库，尤其是用户就餐数据表及相关营养数据表，体量比较大，平均每天都有几百万条数据。因此，需要对数据库进行分表分库。数据库分表分库有两种实现方法，一种是通过JDBC的方式直接在服务端实现分表分库逻辑。另一种是通过增加中间件，以代理的形式进行，分表分库的逻辑在代理层进行实现。经过深思熟虑，我们采用以代理策略的形式进行分表分库，定义了CommonConnect接口，创建了实现接口的实体类DataConnect（根据实现分表分库规则，实现内部各数据库及表的的连接）,ProxyConnect,其中ProxyConnect提供对外服务，当被请求时，使用ProxyConnect来获取DataConnect类的对象。这样无需在应用层实现分表分库逻辑，同时解耦了应用层与数据库分表分库的复杂性。在代理层根据业务需要实现了，以用户ID、日期分表分库的逻辑，实现了数据库在横向与纵向的扩展的同时，对业务层的对接没有任何影响。实现了职责清晰的同时提高了扩展性。

• 在软硬件团队的努力，及相关营养学教授的支持，经过10个月的奋斗，在2020年初，项目上线了。至今已有一百多家单位使用，总共三千多台智能自助餐设备接入平台，注册用户五十来万，两年多以来，整个系统运行稳定。由于架构设计及开发时就考虑到本地化、分表分库等功能，并利用了上面论述的三种设计模式：观察者模式、策略模式、代理模式，随着用户的增长没有出现明显的性能的瓶颈。整个系统得到了老板以及客户的好评。

• 当然在运行过程中也有一些待改进的事项，例如，后台操作界面的交互体验有待提升、随着客户量的进一步上升，需要将SAAS进一步扯分，进行微服务化等。毕竟餐饮行业的信息化与其他行业如：金融，电商相比还算相对落后的，在后续的学习和工作中，我将不断的充电学习向更大的系统架构学习，提升自己的专业技术水平，更好的完成系统架构设计的工作。同时根据上面的不足，进一步优化自助就餐及营养健康分析系统的稳定性、性能、以及安全性。