小程序里的where正则查询如何使用变量

下面这个代码

.where({ biaoti:/小米/i })
``
这里面的小米怎么换成变量，以便输入框输入内容后进行查询。

var s='小米'; 
var re=new RegExp(s,'i') 
.where({ biaoti:re }) 
  • 文章：为城区量身打造智能内涝安全监测解决方案 中也许有你想要的答案，请看下吧
  • 除此之外, 这篇博客: 【揭秘】一个小团队真正能落地的微服务架构实践中的 三、微服务时代 部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读:

  • 1 服务拆分原则
    “独立，独立，再独立？”先忘记这句话吧！想象是美好的，显示却很骨感。以下拆分方案可以给大家一点参考，有好的经验也可以留言分享。

    1.1 公共库的初始化拆分
    我们把公共的库都放在common里面，这里面包括了log，config，errors等基础库，还有redis，mysql，mongodb等db的连接池初始化，还有rpc的连接池初始化，这里或者用grpc或者用户自己基于go自带的rpc的二次封装等。还有trace等用于追踪请求方便日志查询的基本库。

    这些基础库是我们做微服务的必备，在搭建一个新项目的时候，前期需求讨论评审完成后，编码前期，我们会先把这些公共库的初始化工作都做了，比如db的一些连接池初始化不同项目稍微有一些不同。rpc等连接池代码基本都是能复用的。其他的公共库，直接拖到新项目里就能开搞，大大的规范了代码质量和减少开发周期。

    1.2 根据业务职责拆分
    其实微服务的拆分最根本是一些代码职责的拆分和抽象，这一步和我们模块化的时候思路是一样的。我们将按照要开发的业务功能拆分为不同的项目，而负责不同功能的研发人员就可以在自己的代码项目上进行开发，从而解决了大家无法在开发阶段并行开发的苦恼。
    业务职责拆分

    如上图所示，可以拆分为用户中心、产品中心和订单中心等，支撑整体业务的基础服务业可以相应的进行拆分。

    1.3 各组件之间接口的定义（重点讲）
    公共库和各个业务职责搞清楚后，接下来还不要着急写代码，我们先把各个组件之间接口定义清楚。不然各自写各自的，最后还是一团乱麻。
    先做到以下几点：
    1.3.1 接口协议选型。

    - 现在微服务流行采用的http协议restful接口(语言无关)。
- RMI远程接口调用(Java语言支持)。
- 大数据传递采用文件离线下载的方式(FTP)。
- 状态数据(如果进度条)放在Redis中共享缓存。
- 数据库共享。一般来说微服务的数据库是隔离的，不同微服务不允许直接访问彼此的数据库。如涉及大数据有性能问题时可特殊考虑。

    备注：如果为防止数据被人抓包分析，需要有相对应的加解密处理方案。

    1.3.2 定义接口内容。
    接口内容包含接口名称(url)、输入参数、返回值、错误码。一个典型的restful接口内容定义如下：

    restful示例

    备注：code：100代表成功，message：描述说明，result：返回详细信息可以一般是json格式

    1.3.3 明确接口性能。
    接口性能包括：接口单次响应时间、单次查询返回记录条数和每秒支持调用次数等。数据量比较大的查询接口一把都会设计成分页查询，需要定义好单次查询返回的最大记录条数。

    微服务接口的支撑能力是有限的，必须定义好单位时间内允许的最大请求次数(超过请求次数就不响应或者返回错误码)，否则海量的请求一下涌过来，服务就挂了。对于特殊的服务，还会根据实际情况设定一天的请求次数上限等。

    1.3.4 做好接口管理。
    上面说了要做那么多事情那么能不能用好并且是持续的用好，接口管理是非常重要的。
    接口管理包括：接口版本管理、接口权限管理、接口管控等；

    为什么要做接口版本管理？
    大家都知道同一个接口随着产品的不断迭代、需求的不断变更都可能面临接口升级（不管是新增还是兼容）。但是不管怎么升级都需要兼容旧的业务使用，为了管理好就需要通过版本号来解决。例如：在URL中带上不同的版本号，需要使用新特性的可以调用新版本的接口；不使用新特性的可以仍然沿用旧版本接口。

    为什么要做接口权限管理？
    对外发布的接口都需要做权限控制，未授权的服务是不允许访问的。可以采用在接口的header参数中加上加密的token作为权限认证。

    后续当整个系统越来越庞大复杂后，各微服务发布的接口需要做可视化管理，包含服务的注册、发布、调用、下线都需要在统一的运维平台上操作。
    为什么要做接口管控？
    前面提到的接口版本管理对接口不同版本的兼容处理是不可能不限支持下去的。发布旧版本接口的下线公告到期后，如果在监控平台上发现旧版本接口已无人调用就可以下线了，如果还有人调用则可以通知他进行限期整改。

    1.4 开始分工写自己的组件
    这样就可以分配任务编写代码啦。每个开发人员都是相对独立的开发，并且接口也定义好了，公共库也都已经初始化完毕，然后开发就是完全并行了。编写完之后，自己的组件可以依靠单元测试，做一些基本的测试。然后联调即可。

    2 技术框架选择
    来看一下经典的微服务架构图：
    经典的微服务架构图

    主要包含11大核心组件，分别是：

    核心支撑组件

    • 服务网关Zuul
    • 服务注册发现Eureka+Ribbon
    • 服务配置中心Apollo
    • 认证授权中心Spring Security OAuth
    • 服务框架Spring MVC/Boot

    监控反馈组件

    • 数据总线Kafka
    • 日志监控ELK
    • 调用链监控CAT
    • Metrics监控KairosDB
    • 健康检查和告警ZMon
    • 限流熔断和流聚合Hystrix/Turbine

    看到这里是不是想说：“尼玛，这是几个人小团队能玩起来的？确定不是让我们996 变 007 吗？”，我也想说我们也不是用的这个，一般是给别人吹牛用的，哈哈哈哈！
    我们来看下面这张技术架构图，大家会好理解许多。
    微服务

    这张图大部分业务都通用，根据团队自身情况去选择技术来满足业务需求。

您好，我是有问必答小助手，您的问题已经有小伙伴帮您解答，感谢您对有问必答的支持与关注！
PS：问答VIP年卡 【限时加赠：IT技术图书免费领】，了解详情>>> https://vip.csdn.net/askvip?utm_source=1146287632