Group Details Private

administrators

 

Member List

  • 金易联B端SDK使用前说明文档

    一、申请SDK appkey

    将申请appKey所需资料以表格的形式发送至凡泰邮箱:
    邮箱地址:xuguoyong@finogeeks.com
    邮件主题:金易联SDK申请。

    邮件内容如下:

    机构名称 客户端 应用名称 BundleId 服务器域名 URL Scheme
    机构1 Android
    机构2 iOS

    注:申请结果会在1-2个工作日内回复,如需加急审核,请联系凡泰商务。

    二、SDK集成文档

    金易联SDK集成文档链接如下:
    https://docs.finogeeks.club/docs/mobile/#/ios-doc

    posted in 金易联
  • 金易联账号体系对接说明

    金易联作为一个企业的一个数字管理平台,有单独的管理后台界面,管理员可以在管理后台上进行相关信息的查看,以及相关的功能管理。由于企业一般有自己的CRM管理系统,所以需要把企业的CRM信息和金易联的管理后台B端员工信息进行打通,使用CRM系统来进行统一认证。

    主要分两种场景来介绍如何对接企业的CRM管理系统:

    1.)企业的APP集成凡泰的SDK进行登录;
    2.)管理后台的员工进行账号登录;

    1.SDK账号系统对接说明:

    一般情况下,企业的APP会有自己的账号密码登录,如果让用户在输入用户名密码来登录凡泰的SDK,会影响用户的体验,所以在SDK的集成侧,凡泰金易联SDK的登录主要是通过Token来进行登录认证;

    0_1591151714291_bc3c1f25-b0a5-4841-ad60-b8c5c302d762-image.png
    表 1SDK登录对接流程图

    2.管理后台员工登录对接说明:

    目前金易联管理后台的登录方式是通过员工的账号密码进行登录的,在对接的情况下,需要到客户的CRM系统进行账号密码的认证,CRM系统校验通过后,再签发金易联相关的Token信息给到管理后台的客户端进行访问;
    0_1591151721566_42a8136b-6043-42a7-a3f3-a15c4414ae08-image.png
    表 2管理后台登录对接流程

    相关说明:

    用户在使用金易联的管理后台进行导入的时候,优先考虑使用的Account账号为CRM管理系统的账号,方便后续的对接同步;

    0_1591151730898_de0d16b7-9018-42d3-98fe-11afad3e7952-image.png

    需要客户提供相关的接口信息:

    1.通过Token 校验用户身份信息的接口;
    2.校验用户名和密码的接口,并返回用户相关的有效信息;

    posted in 金易联
  • 数据上报JS-SDK说明

    ⾦易联提供⽆埋点数据上报SDK,⽬前⼩程序端⽀持主流的mpvue和Taro框架,以及Web端(受限于浏
    览器,部分数据与⼩程序端会有差异)。

    ⽆埋点采集事件逻辑

    ⽤户画像

    开发者在应⽤启动的时候,需要主动配置部分⽤户数据,包含但不限于⽤户ID、⼩程序appId、⽤户名
    称等等;同时SDK会⾃动采集系统相关数据,包含但不限于操作系统、⼿机型号、⽹络状态等等;后续
    发送的所有埋点事件会统⼀记录上述元数据。
    Web端只能获取操作系统等有限的数据。

    访问数据

    每次⽤户打开⼩程序的时候,发送⼀条 应⽤打开 消息,对应的数据指标是打开次数。发送数据包含但不
    限于以下信息:进⼊⻚⾯、进⼊时间、场景值、来源⼩程序或 App、设备信息、微信信息、应⽤版本
    号。
    每次⽤户关闭⼩程序的时候,关闭动作包括退出⼩程序回到微信或APP,会发送⼀条 应⽤关闭 消息,会
    根据这个消息来计算应⽤访问时⻓。发送数据包含但不限于以下信息:退出⻚⾯、退出时间。
    Web端暂时没有上报应⽤级别事件,主要以⻚⾯为纬度。

    ⻚⾯数据

    每次⽤户访问⼀个新的⻚⾯,发送⼀条 ⻚⾯打开 消息,对应的数据意义是⻚⾯分析。发送数据包含但不
    限于以下信息:⻚⾯信息、打开时间、⻚⾯来源、⻚⾯标题、⻚⾯级变量。
    每次当⽤户点击转发按钮时,会弹出转发框,这时会发送⼀条 要转发消息 消息。这是⼀个⾃定义事件,
    数据包含以下信息:事件时间、所在⻚⾯、转发动作来源、转发⻚⾯标题和转发⻚⾯路径。注意这个事
    件不代表⽤户真正转发了消息到聊天⾥⾯,⽽是⽤户触发了转发动作。如果要跟踪成功转发消息事件,
    建议在 onShareAppMessage 的 success callback ⾥⾯发送⼀个⾃定义事件。
    Web端主要包含⻚⾯访问、⻚⾯离开和停留时间等事件,⽆转发事件。

    ⾏为数据

    对于⽤户在⻚⾯发⽣的⾏为,如果这个⾏为有绑定事件⽐如 bindtap,并且在你的⼩程序⾥⾯进⾏处
    理,那么 SDK 可以捕获到这些事件。开发者需要在⾃定义事件配置⽂件中主动声明需要收集的事件类
    型、⻚⾯和元素等信息,后续SDK会⾃动采集相关事件并进⾏上报。
    Web端也⽀持⾃定义事件,可⾃动将URL参数转化为业务参数,并⽀持声明扩展业务参数,在SDK⾃动
    收集的时候⼀并上报。

    使⽤⽅式

    以下说明以⼩程序SDK为例⼦说明接⼊流程,具体的接⼝⽂档与接⼝参数待补充(可能会有细微的调
    整)。

    1. 引⼊JS-SDK
    import fcTrack from 'FcTrack';
    
    1. 初始化SDK配置,在项⽬⼊⼝进⾏初始化
    // 设置SDK配置,包括⾃定义事件的配置
    fcTrack.setPara({
     appid: '应⽤ID(⼩程序appId)',
     app_name: '应⽤名称',
     app_version: '应⽤版本',
     server_url: '上报服务端地址',
     actionEventData: [
    {
    path: '⼩程序⻚⾯路径',
    methodTracks: [{
     method: '事件处理函数⽅法名',
     chineseMethod: '事件中午名称',
     dataKeys: ['元素中声明的data,例如data-productId="123456"等业务数据'],
     }]
    }
     ],
     app_key_id: '应⽤Key',
     autoTrack: {
     appLaunch: false,
     },
    });
    // 传⼊Taro或mpvue实例,SDK需要劫持实例的事件实现数据收集
    fcTrack.initTrack({ taro: Taro });
    
    1. 上报⽤户信息和ID,⽤户信息通常在应⽤登陆完成后才进⾏获取,需要调⽤SDK接⼝主动上报。
    fcTrack.setOpenid(openId); // 设置⽤户ID
    fcTrack.setUserInfo({ // 设置⽤户信息
    user_id: '⽤户ID',
     name: '昵称',
     avatar: '头像',
     gender: 1, // 微信数据 0 未知,1男性,2⼥性
     country: '国家',
     province: '省份',
     city: '乘⻋',
    });
    
    1. 声明⾃定义事件event_name及其他业务参数,受限于Taro框架,部分事件需要⼿动声明
      event_name,⾃定义事件上报需要携带的业务参数,可以通过声明的⽅式,与事件⼀并上报。
    <Button
    className='iconfont icon-service_btn_press'
    onClick={handleClick}
    data-event_name='handleClickConsult'
    data-fcid={staffId}
    data-timelineid={timelineId}
    ></Button>
    
    posted in 金易联
  • App集成金易联SDK技术方案

    一、申请SDK appkey

    将申请appKey所需资料以表格的形式发送至凡泰邮箱:
    邮箱地址:xuguoyong@finogeeks.com
    邮件主题:金易联SDK申请。
    邮件内容如下:

    机构名称 客户端 应用名称 BundleId 服务器域名 URL Scheme
    机构1 Android
    机构2 iOS

    注:申请结果会在1-2个工作日内回复,如需加急审核,请联系凡泰商务。

    二、SDK集成文档

    金易联SDK集成文档链接如下:
    https://docs.finogeeks.club/docs/mobile/#/ios-doc

    三、宿主app交互时序图

    1.接入方app调用接入方服务器进行登录。
    2.接入方服务器校验当前的用户合法,向金易联认证服务端请求认证。
    3-4.金易联认证服务端认证用户成功,返回认证token给接入方服务器。
    5.接入方服务器返回认证token给接入方app。
    6.接入方使用认证token登录金易联SDK
    7.登录成功,返回用户信息。
    8.接入方科可以使用SDK开放的所有的API接口。
    9.API接口详见:
    0_1591151216717_12e936da-d075-44f5-8928-ce0b6b725b93-image.png

    说明: 金易联SDK提供 用户名密码、token、手机号验证码三种登录方式,上述的时序图描述的是SDK token登录的方案,其他方案类似。

    posted in 金易联
  • 金易联技术方案

    1.系统架构及主要模块说明

    1.1主要模块说明

    金易联整体方案包含的主要模块有:基础通讯平台、验证中心、关系链、平台API、工单系统、派单规则、积分规则、敏感词、知识库、客户信息、员工信息、产品中心、统一网关、金易联管理后台、Android员工端、iOS员工端、小程序客户端、机器人框架。主要模块逐一介绍如下:

    (1)基础通讯平台,提供私聊、加密私聊、群聊、加密群聊、群管理等技术通讯能力,并开放相应的REST API。
    (2)验证中心,提供登入、登出验证功能。其中,金易联本身不包含用户账号系统,针对用户账号密码或者Token的验证,金易联提供标准的验证接口协议,由具体机构实现,验证中心在用户登陆时,通过调用具体机构实现的账户验证接口完成用户身份的确认。
    (3)关系链,负责基础通讯平台的好友关系管理,包括邀请、接受、拒绝、删除好友等功能。
    (4)平台API,基于基础通讯平台及其他服务模块提供的API,提供更加丰富、高级的API,供终端和服务端使用。比如,批量操作群成员等。
    (5)工单系统,管理咨询工单、留言工单、知识库工单等各种类型工单,包括派单、接单等功能。
    (6)派单规则,管理支持工单系统的各种派单规则的增删改查及上下架,派单规则决定一个工单应该派发给哪些用户,比如一个咨询工单应该先派给最近的营业部客服人员,再到同城营业部的客服人员,再到全国营业部的客服人员,最后到专项小组等。
    (7)积分规则,管理计算员工处理工单情况的积分计算规则,服务于员工激励。
    (8)敏感词,管理敏感词的增删改查及上下架,用于识别工单、聊天、知识库等是否涉及敏感词的合规场景。
    (9)知识库,供机构录入各种业务知识,支持客服和投顾在服务客户的过程中随时搜索知识库,即时解答客户的业务问题。
    (10)客户信息,客户信息管理系统,提供单条、批量客户信息导入接口供机构灌入客户信息,员工在服务客户时,能直接从聊天窗口顶部看到客户的身份、持仓、盈亏等信息。
    (11)员工信息,员工信息管理系统,提供单条、批量员工信息导入接口供机构灌入员工信息,客户在向员工咨询时,能直接从聊天窗口顶部看到员工的职位、营业部、执业编号等资质信息。
    (12)统一网关,对所有从终端访问金易联后台的请求进行鉴权、流控、路由等操作。
    (13)金易联管理后台,提供一个PC上的Web版管理终端,对知识库、敏感词、产品中心、积分规则、派单规则、人员等进行可视化管理操作。
    (14)Android员工端,提供给员工使用的Android版APP。
    (15)iOS员工端,提供给员工使用的iOS版APP。
    (16)小程序客户端,提供给客户使用的小程序版APP。
    (17)机器人开发框架,一个用于开发机器人程序的后台开发框架,开发者只需关注机器人业务逻辑。本质上,一个运行的机器人程序可以认为是机器人使用的终端,正如普通用户使用Android/iOS/小程序终端一样。金易联方案中的机器人有:智能客服,自动解答客户的业务问题,出现解答不了的情况时,客户端可以留言或者转人工客服;通知助手,将员工对客户留言问题的回复及时通知给客户;合规助手,当员工在服务客户的过程中,将聊天内容出现敏感词的情况通知给具体的合规管理人员。

    1.2系统架构

    金易联整体系统架构图,如下所示:

    0_1590629076738_93526759-e919-4689-8194-7ba9bdf6450d-image.png

    2.系统监控方案

    2.1监控方案技术架构

    金易联监控方案采用到的技术和工具主要包括:Docker、Rancher、Prometheus、Grafana,及自研发。整体技术架构如下所示:

    2.2监控范围

    2.2.1机器层面的监控

    对机器内存、CPU、存储的使用率、磁盘的读写速度、网络吞吐拥塞、建立的tcp连接数、文件描述符可用量等方面进行监控,如下图所示:

    0_1590629478471_60b9c00c-0287-4c29-a540-f1b588dfe297-image.png

    2.2.2容器层面的监控

    监控容器健康状态、内存、CPU、网络吞吐等,侧重于容器本身的指标,如下图所示:

    0_1590629496979_33f3d6a1-a4de-49fc-8f9c-e2bf5daa56d0-image.png

    2.2.3服务层面的监控

    主要涵盖:服务是否存活、可用;服务运行期间开放出来各种定制化的指标如连接数、时延、线程数、并发数(覆盖当前和平均水平)、集群服务的节点健康状况、主从节点数等;支持大多数主流关系型数据库、NOSQL存储,以及消息系统的监控,如Postgres、Mysql、Oracle、MongoDB、Redis、ElasticSearch、Memcached、kafka、Nats等。如下图所示为MongDB:

    0_1590629525144_30a0f935-efe8-43ff-a549-a32a5852c831-image.png

    2.2.4业务API层面的监控

    以最终用户的视角,定时探测业务API,监控HTTP请求响应状态码和延时,如下图所示:

    0_1590629551890_8186f241-467d-4c8d-a1be-5f06e3d2cec7-image.png

    2.2.5统一监控

    提供一个统一的页面展示当前所有可能运行异常的服务,便于运维人员了解整体服务的健康状况。如下图所示,可确认当前服务整体运行无异常:

    0_1590629577255_45403ec9-d531-4978-b000-3a06150273e7-image.png

    2.3告警

    监控指标统一汇集到prometheus后,根据配置到prometheus中的告警策略,产生告警,最终通过配置告警渠道发送出去。告警渠道支持短信、Finchat、企业微信,及其他开放消息推送接口的方式。此外,告警自动或手动恢复后还会发送恢复通知。具体如下图所示:

    0_1590629596596_c0030bc0-f67a-4217-be85-74ee111626d2-image.png

    3.系统灾备及扩容方案

    3.1灾备方案

    金易联灾备方案包括服务灾备和存储灾备。

    3.1.1服务灾备

    金易联整体架构遵循微服务的设计原则,每个服务职责单一、无状态,支持多实例高可用部署,任一实例出现问题均不会影响该服务的可用性。

    3.1.2存储灾备

    金易联使用到的存储有:MongoDB、Postgres、Minio、Redis,具体的灾备方案分别如下:
    (1)MongoDB,采用至少三个节点的副本集方式部署;
    (2)Postgres,采用至少一主一从的主从方式部署;
    (3)Minio,用于文件存储,采用至少2个实例规模的集群方式部署;
    (4)Redis,用于缓存,数据的允许数据丢失,采用一主一从部署。

    3.2扩容方案

    金易联扩容方案包括服务扩容和存储扩容。

    3.2.1服务扩容

    金易联整体架构遵循微服务的设计原则,每个服务职责单一、无状态,支持动态水平伸缩,通过Rancher API或者管理界面操作,可以秒级动态增加服务实例个数,应对线上访问量的增加

    3.2.2存储扩容

    金易联使用到的存储有:MongoDB、Postgres、Minio、Redis,具体的扩容方案分别如下:
    (1)MongoDB,结合当前访问和存储规模及增长趋势,综合采用启动MongoDB自动分片功能、增加MongoDB集群节点数量、读写分离、基于业务层面分片(分库、分表、多集群)等一或多种方法进行扩容;

    (2)Postgres,结合当前访问和存储规模及增长趋势,综合采用增加从节点数量、读写分离、数据归档、基于业务层面分片(分库、分表、多集群)等一或多种方法进行扩容;

    (3)Minio,结合当前访问和存储规模及增长趋势,综合采用增加集群节点数量、数据归档、基于业务层面分片(多集群)等一或多种方法进行扩容;

    (4)Redis,用于缓存,扩容必要性不大,确实需要的话,可以采用根据键值Hash分片的集群方式部署。

    4.系统部署手册

    4.1部署基础环境

    在部署服务之前,需要每台机器都安装Docker以及Docker Compose,目前支持1.12.6,1.13.1,17.03.2三个版本。

    4.1.1安装Docker

    安装docker17.03的脚本
    curl https://releases.rancher.com/install-docker/17.03.sh | sh
    

    4.2部署Rancher平台

    目前金易联的所有后台服务都是通过Rancher的方式来部署。所以在部署金易联之前,需要先准备足够的机器,需要把每台机器加入到Rancher的环境管理中。

    4.2.1Rancher集群模式部署
    在高可用(HA)的模式下部署运行Rancher Server,需要暴露一个额外的端口,添加额外的参数到启动命令中,并且运行一个外部的负载均衡。

    HA部署需求:

    因为版本升级架构改变,Rancher 2.x目前有两种HA安装方法:

    1.RKE HA

    这种HA安装方法基于RKE部署K8S集群和Rancher HA,此方法支持2.0.8以及之前的版本。

    2.Helm HA

    这种方法通过RKE部署K8S集群,再通过Helm去安装Rancher HA。此方法支持2.0.8以后的版本。

    具体的安装方法可以参考Rancher的官方网站:
    https://www.cnrancher.com/docs/rancher/v2.x/cn/installation/server-installation/ha-install/helm-rancher/

    4.3部署数据库服务

    金易联整套后台服务需要用到的数据库服务包括Postgres、MongoDB、Redis等数据库服务。

    4.3.1部署数据存储基础服务

    数据存储基础服务包括Postgres数据库服务,Mongo数据库服务,Minio对象存储服务。
    Postgres提供主从复制,Postgres的主从复制流程如下:

    0_1590629688131_45268479-6804-4540-8ced-64b92a477ff0-image.png

    图 1 Postgres主从模式

    在部署Postgres时,需要先准备2台物理机器,2台机器的物理硬盘要尽可能的大些。在1台机器上设置label:“finochat.pg-master=yes”, 在另外1台机器上设置label:“finochat.pg-slave=yes”。凡泰提供Postgres主从之间的复制采用异步复制的方式。

    MongoDB提供的是Replica Sets模式(副本集)。MongoDB官方目前已不推荐使用主从模式,取而代之的是副本集模式。副本集其实是一种互为主从的关系,可理解为主主模式。副本集将数据复制,多份保存,不同服务器保存同一份数据,在出现故障时自动切换。副本集比传统的Master-Slave主从复制有改进的地方就是它可以进行故障的自动转移,如果我们停掉副本集的一个成员,那么剩余的成员会再自动选举为一个成员,作为主库。

    0_1590629718764_e141c3a7-ed07-47e9-b0ee-2b41d6dae1a1-image.png

    图 2 Mongo副本集模式

    在部署MongoDB时,需要先准备三台机器,在每台机器上设置label: “mongo.env=yes”,用于调度MongoDB服务。(备注:三台机器部署MongoDB服务)。
    Storage的catalog提供了Postgres和Minio这两个基础服务。Mongo-cluster的catalog提供了MongoDB的存储服务。在设置完主机的调度标签后,接下来我们开始部署基础的数据库存储服务。

    在Rancher的管理界面中点击catalog中选择“storage”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出storage服务的具体配置信息:
    0_1590629749779_67d84625-3f92-40db-95a9-0a6294df5321-image.png
    图 3 storage服务catalog

    storage的配置参数可以保持默认提供的即可,点击“Launch”进行部署。storage服务部署成功后,可以看到如下的服务列表:
    0_1590629774082_eedcd159-720b-4b34-a350-30184a3d5a7c-image.png
    图 4 storage服务列表
    storage的服务启动之后,只是拉起了postgres和minio的存储服务,接下来把mongo的服务加入到storage的namespace,点击“Launch”进行部署。
    0_1590629800092_ff8bd057-de0e-4ba4-8589-7cbb04b5f860-image.png
    图 5 mongo服务

    至此,基础的存储服务已经部署好了。

    4.3.2部署Redis

    Redis数据库主要提供一个缓存数据功能,Chat 服务中会使用Redis进行热点数据的缓存,接下来说明如何部署一套Redis集群服务。

    在Rancher的管理界面中点击catalog中选择“redis-cluster”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出Redis cluster服务的具体配置信息:
    0_1590629881296_33216f4e-6b6b-4d0f-af6f-b9d6590d938b-image.png
    图 6 redis服务catalog

    Redis的配置参数可以根据默认的即可,点击“Launch”进行部署。Redis服务部署成功后,可以看到如下的服务列表:
    0_1590629903724_ca42a73b-5890-4241-a1e4-fd16a38638a6-image.png
    图 7 redis服务列表

    4.4部署Kafka服务

    Kafka作为消息队列的中间件服务,FinChat聊天服务基于Kafka作为消息总线,而Kafka依赖于Zookeeper存储Broker、主题和分区等元数据信息。

    在部署zookeeper和Kafka之前,需要先对主机设置调度标签。在三台要署kafka的机器上添加label: “zookeeper.env=yes” 和 “kafka.env=yes”,用于调度Kafka 和Zookeeper服务。
    在Rancher的管理界面中点击Catalog Apps 中选择“zookeeper”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出Zookeeper的集群配置信息:
    0_1590630551284_68895646-5779-4238-8c64-07c917d4affb-image.png
    图 8 zookeeper服务catalog

    Zookeeper的Catalog默认提供的是3个节点的集群,默认的数据存储是挂载到“/mnt/data/dendrite/zookeeper”的文件夹下,如果需要修改挂载的路径,可以根据实际情况进行配置,点击“Launch”进行部署。

    0_1590630575634_712a25c8-c039-444e-b3a3-d861f1f45e17-image.png
    图 9 zookeeper服务详细列表

    zookeeper服务部署成功后,接下来可以开始部署Kafka集群。在Rancher的管理界面中点击Catalog Apps 中选择“kafka”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出Kafka的集群配置信息:
    0_1591061085086_c110137e-487d-4548-a3b8-118efb39b10a-image.png
    图 10 kafka服务catalog

    需要特别注意的是,Kafka这里配置了连接Zookeeper 的服务地址,这里通过Rancher 的ServiceName.StackName:Port方式进行访问,默认情况下,部署的是zookeeper的stack名称,点击“Launch”进行部署。Kafka服务部署成功后,可以看到如下的详细列表:
    0_1591061113259_83c82938-18a1-416c-befe-b5798d837e36-image.png
    图 11 kafka服务详细列表

    4.5部署金易联基础服务

    金易联基础服务主要是提供聊天相关的平台级功能,作为整个金易联的服务总线。在部署之前,需要先准备好server的域名,以及苹果推送服务的APNs证书文件。准备若干台服务器(具体数量和部署规模相关),用来部署金易联基础服务,其中至少一台要有访问外网的权限,用于苹果消息推送。

    在Rancher的管理界面中点击Catalog Apps中选择“chat”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出Chat服务的具体配置信息:
    0_1591061135747_990862aa-6a99-4def-a1a3-42d8307b23b2-image.png
    图 12 IM内核 catalog

    chat涉及的配置参数比较多,具体各个参数的含义如下:

    catalog配置说明

    1. Broker Nodes: Kafka的Broker节点配置信息
    2. DB URI: Postgres数据库链接地址字符串
    3. CACHE RUI: Redis数据库连接字符串
    4. DOMAIN NAME: IM的域名信息
    5. FED CERT: 配置的证书文件,保持默认即可;
    6. private key: 
    7. upload url: 员工端类型,使用1来表示员工端
    8. download url: 客户端类型,使用2来表示客户端
    9. thumbnail: 获取头像缩略图的URL
    10. as_id: AS服务的App Id 
    11. as_url: AS服务的URL地址,指向AS服务的地址,保持默认值即可
    12. as_token: AS服务的Token,需要跟Platform的msg-bridge的as_token保持一致;
    13. hs_token: HomeServer的Token信息,需要跟Platform的msg-bridge的token保持一致;
    14. sender_localpart: 匹配过滤Sender的信息,@*.表示接收所有的用户消息;
    15. as_namespace_users: 需要过滤的某个用户的信息,AS默认接收所有的消息;
    16. as_namespace_alias: 需要过滤的某个房间的别名信息,默认不填;
    17. as_namespace_rooms: 需要过滤的房间的信息,默认不填
    

    确认上述的配置信息准确无误后,点击“Launch”进行部署。chat服务部署成功后,可以看到如下的详细列表:
    0_1591061164515_951d78f7-d2f6-4edf-b86a-0c4aefb7e3a4-image.png
    图 13 chat服务详细列表

    网关服务提供FinChat的所有访问入口,该服务主要提供服务的路由、路由配置初始化和一个可视化的管理面板,查看当前gateway的路由配置信息。

    在Rancher的管理界面中点击Catalog Apps中选择“gateway”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出gateway服务的具体配置信息:
    0_1591061189103_88e9437f-890f-47dd-92ea-95007a6b2b62-image.png
    图 14 网关服务catalog

    确认上述的配置信息准确无误后,点击“Launch”进行部署。服务部署成功后,可以看到如下详细的列表:
    0_1591061217891_582d7953-7072-4344-8697-1fc86af36c59-image.png
    图 15 gateway 服务列表

    gateway服务部署成功后,接下来继续部署platform相关的服务。在Rancher的管理界面中点击Catalog Apps中选择“platform”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出platform服务的具体配置信息:
    0_1591061247243_67bc1511-eccd-4c7f-b3f9-ddf16ae12a50-image.png
    图 16 platform服务catalog

    需要注意的是这里AS token 和HomeServer Token 以及Id需要和chat 的Stack中的配置信息保持一致,否则msg-bridge无法收到HomeServer 推送过来的消息。确认上述的配置信息准确无误后,点击“Launch”进行部署。服务部署成功后,可以看到如下详细的服务列表:
    0_1591061270113_ab1e7c39-3f30-423a-a64a-6e7919d262c4-image.png
    图 17 platform服务详细列表

    在platform服务部署成功后,接下来继续部署Auth服务,该服务主要是对接客户的登录认证。

    在Rancher的管理界面中点击Catalog Apps中选择“auth”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,选择后会弹出auth服务的具体配置信息:
    0_1591061290295_36e097ac-0cda-43d8-8d57-2b1383658fb8-image.png
    图 18 auth服务catalog
    确认上述的配置信息准确无误后,点击“Launch”进行部署。Auth服务部署成功后,可以看到如下的详细信息:
    0_1591061318267_5a5dac49-b97f-4c26-8425-ded3dbcf0f8e-image.png
    图 19 auth服务详细列表
    部署完auth服务之后,接下来继续部署adapter服务,该服务主要用于对接用户登录认证的适配。

    在Rancher的管理界面中点击Catalog Apps中选择“adapter”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.2”版本,选择后会弹出adapter服务的具体配置信息:
    0_1591150878242_4eace05c-6116-4fea-88fe-49183e541542-image.png
    图 20 adapter服务catalog

    上述小程序的APP_ID和APP_SECRET需要根据实际的使用情况进行配置。确认上述的配置信息准确无误后,点击“Launch”进行部署。

    4.6部署金易联业务服务

    金易联业务服务主要用于智能客服、系统派单、工单管理、知识库管理和搜索、敏感词管理等。

    在Rancher的管理界面中点击catalog中选择“swan”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择“1.0.0”版本,如果当前模板版本有更新的版本,则选择最新的版本,选择后会弹出服务的具体配置信息:
    0_1591150921351_e96f3eba-d9da-42e1-a210-3abe244aea71-image.png
    图 21 工单系统catalog

    检查相关的配置信息,确认准确无误后,点击“Launch”进行服务的部署。在工单系统服务部署成功后,即可看到如下的服务列表,具体如下:
    0_1591150941562_871f570b-14be-4ed5-8376-a9ad595da274-image.png
    图 22 swan服务列表

    金易联业务服务涉及的参数进行相关的说明:

    1. max_advisory: 咨询工单最大未处理数, 默认值1000
    2. knowledge_static_prefix: 知识库静态页面地址,主要修改域名部分
    3. tag_text_url: 智能标签服务调用地址
    4. mongo_domain: 数据库域名信息,使用rancher的service-name.stack-name方式
    5. mongo_auth: mongo数据库密码
    6. knowledge_port: 知识库搜索端口,保持默认值;
    7. detall_url: 知识库详情前缀,保持默认值
    8. assist_id: 智能助理账号id,根据实际情况进行变更
    9. assist_password: 智能助理密码,根据实际情况填写
    10. customer_id智: 能客服账号id
    11. customer_port: 智能客服接口端口,保持默认值即可
    12. customer_password: 智能客服密码
    13. bots_init: 机器人注册信息,用户客户初次登录添加对应的机器人账号;
    14. minaAppID: 小程序的AppID;
    15. avatar_url: 机器人初始化头像地址;
    

    4.7部署监控

    整套监控方案包括:

    (1)cadvisor: 提供容器监控服务,该服务会占用宿主机的18080端口,每台宿主机都需要部署该服务;
    (2)node-exporter: 宿主机监控服务,该服务会占用宿主机的9100端口,每台宿主机都需要部署该服务;
    (3)grafana: 监控展示面板;
    (4)prometheus: 监控数据存储;
    (5)alertmanager: 监控告警管理中心;
    (6)alert-webhook: 监控告警通知服务;
    (7)api-porber: API探测服务;
    在了解了整套监控方案后,根据我们提供的catalog来部署一套监控服务。在部署监控服务之前,需要在部署该监控服务的宿主机上添加以下两个label: “monitor.grafana=finochat”,“monitor.prometheus=finochat”。
    在Rancher的管理界面中点击catalog中选择“monitor”这个Stack, 点击“View Details”进入到这个Stack的详细信息页面,在“Template Version”选择 1.0.0版本,选择后会弹出监控服务的具体配置信息:
    0_1591150969917_2c778cb2-35bc-45a5-920b-9e055b0588c7-image.png
    图 23监控配置详情

    上述变量配置中,每个变量的具体含义如下:

    catalog配置说明

    1. app: 用于设置机器的label,使用默认值即可
    2. admin password: 设置grafana的admin用户密码
    3. db path: 指定配置文件路径,不同机构的grafana面板配置不同
    4. prometheus config file: 设置promethues收集监控数据的配置文件,不同机构的监控指标不同
    5. alarm bot userid: 报警机器人id
    6. environment: 作为监控信息的机构环境名称
    7. api host: 设置api探针监控进行服务探测的api地址
    8. auth userid: api探测使用的用户id(去除finochat前后缀)
    9. auth fcid: api探测使用的用户id
    10. auth app token: api探测使用的用户token
    11. auth app type: api探测使用的app type
    12. auth login type: api探测使用的用户登陆方式
    

    在部署时,主要确认下“alarm bot userid”账号是否存在可用。信息确认无误以后,点击 “Launch”进行部署。部署成功后,在Rancher上看到每个服务的状态都为active,具体如下:
    0_1591150991668_76b7af78-9e33-4351-81a2-34b0f8455bf3-image.png
    图 24监控服务详情

    服务正常运行后,可以登录到grafana查看监控面板,看看数据是否正常。grafana默认密码为:fino123456

    5.机构对接指南

    金易联与机构的对接方式有两种:(1)金易联提供标准的接口供机构调用;(2)金易联提供所需要接口的协议,由机构调用实现。金易联按照第一种方式对接机构的模块三个:客户信息、员工信息、产品中心;按照第二种方式对接机构的模块有两个:验证中心、关系链。以下为每个模块的对接接口详情:

    5.1客户信息

    5.1.1导入一个客户

    HTTP POST
    /api/v1/swan/customer/retail
    请求的body是:

    field type
    retailId string 客户的fcid,不允许大写字母。形如:@retail_xxxx:domain 必填
    name string 客户名字 必填
    gender string 性别,默认为空字符串,F:女 M:男 可选
    avatar string 头像url 可选
    phone string 手机号 可选
    email string 电子邮箱 可选
    type int 客户类型。1:VIP 2:增量 3:存量 默认值0:未知 可选
    level int 账户级别 0:游客 1:注册账户 2:交易账户 可选
    from string 客户来源,由机构设置 可选
    address string 客户地址 可选
    department string 客户所属营业部。填营业部名字即可 可选
    fundCode string 资金账户 可选(如果是交易账户,此为必填项)

    profile json 客户画像,由机构设置。默认为: {riskLevel: 0, investmentVariety: 0, investmentPeriod: 0} 可选
    advisers jsonarray 签约投顾。形式为:{typeId:"" , typeName: "", staffId: ""} 可选
    visitingCard jsonarray 客户名片,这里是机构自定义样式和内容。是一个二维数组,其中value是内容;ratio占布局的百分比;align代表对齐方式,取值是0,1和2,分别代表居左,居中和居右形如:[[{"value": "", "ratio": 10, align: 0}, {}],[{}]] 可选
    openAccount bool 是否开户 可选
    signRisk bool 是否签风险协议书 可选
    rightsAll json 已开通业务。形如:{"shA": "1", "shB": "1"} 可选

    5.1.2批量导入客户

    HTTP POST
    /api/v1/swan/customer/retail/_bulk
    请求的body是:
    {
    "docs": [{}, {}] // 客户信息的数组,客户信息和单个客户导入一样
    }

    5.1.3以Excel方式批量导入客户

    通过管理后台页面的批量导入按钮将Excel文件上传(Excel模版可以在管理页面下载)。

    5.2员工信息

    5.2.1导入一个员工

    HTTP POST
    /api/v1/swan/manager/staff
    请求的body是:
    field type
    userId string 员工的fcid,不允许大写字母。形如:@staff_xxxx:domain 必填
    name string 员工的名字 必填
    phone string 手机号 可选
    mail string 邮箱 可选
    power bool 是否有接单权限,默认是true 可选
    notice json 抢单,派单的通知。rush是抢单,dispatch是派单,默认是{rush: true, dispatch: true} 可选
    avatar string 头像地址 可选
    jobTitle string 职位 可选
    practiceNum string 编号 可选
    expiryDate number 过期时间 可选
    salesDepartment string 营业部 可选
    hotline string 投诉电话 可选
    online bool 是否在线,默认是false 可选
    group [string] 所属分组,值是所属的组的ID 可选
    role string 角色,主要用于数据的权限 可选
    visitingCard [json] 员工名片,这里是机构自定义样式和内容。是一个二维数组,其中value是内容;ratio占布局的百分比;align代表对齐方式,取值是0,1和2,分别代表居左,居中和居右形如:[[{"value": "", "ratio": 10, align: 0}, {}],[{}]] 可选
    others json 保留字段,机构可在这里添加更多自定义的字段 可选

    5.2.2批量导入员工

    HTTP POST
    /api/v1/swan/manager/staff/_bulk
    请求body是:
    {
    "docs": [{}, {}] // 员工信息的数组,员工信息和导入单个员工一样
    }

    5.2.3以Excel方式批量导入员工

    通过管理后台页面的批量导入按钮将Excel文件上传(Excel模版可以在管理页面下载)。

    5.3产品中心

    5.3.1新增一个产品

    HTTP POST
    /api/v1/swan/product/fund
    请求的body是:
    field type
    code string 产品代码 必填
    parentCode string 母产品代码 可选
    name string 名字 必填
    shortName string 简称 可选
    pinyin string 拼音 可选
    riskLevel int 风险等级(0:低 1:中低 2:中 3:中高 4:高)字典表,是可配置的 必填
    investmentPeriod int 投资期限(0:短期 1:中期 2:长期)字典表,是可配置的 必填
    investmentVariety int 投资种类(0:股票 1:期货 2:国债 3:基金 4:信托)字典表,是可配置的 必填
    type int 产品类型(0:大集合 1:小集合 2:定向 3:专项 4:保本固定收益凭证 5:保本浮动收益凭证 6:非保本固定收益凭证 7:PE)字典表,是可配置的 必填
    style int 投资风格(0:混合 1: 单一)字典表,是可配置的 必填
    establishmentDate 时间戳 成立日期 必填
    managementPeriod int 管理期限 必填
    firstPurchase double 首次购买金额 必填
    additionalPurchase double 追加购买金额 必填
    performanceBenchmark double 业绩比较基准 必填
    expirationDate 时间戳 产品到期日期 必填
    updateNote string 数据更新备注 可选
    publishDate 时间戳 发行时间 必填
    promotion bool 是否推荐产品 可选
    author string 更新人 必填
    cumulativeRate string 累计收益(可对接机构系统获取) 可选
    unitNetValue string 单位净值(可对接机构系统获取) 可选
    dailyGain string 日收益(可对接机构系统获取) 可选
    annualIncrease string 年收益(可对接机构系统获取) 可选
    dividendInfo string 分红方式(可对接机构系统获取) 可选
    riskFlag bool 高风险标志(可对接机构系统获取) 可选
    firstPurchaseFlag bool 首次购买限制(可对接机构系统获取) 可选
    assets jsonarray 产品资产构成(可对接机构系统获取)。例如:[{type: "股票", rate: "80" , money: "8.63"}] type是类型,rate是占比,money是金额,以万元为单位 可选

    5.3.2批量新增产品

    HTTP POST
    /api/v1/swan/product/fund/_bulk
    请求的body是:
    {
    "docs": [{}, {}] // 产品的数组,产品信息和新增单个产品一样
    }

    5.3.3以Excel方式批量新增产品

    通过管理后台页面的批量导入按钮将Excel文件上传(Excel模版可以在管理页面下载)。

    5.4验证中心

    机构需要根据金易联提供的协议实现一个接口用于登录认证,由金易联调用。客户和员工的认证共同调用这个接口,但是其POST的请求体和返回的结果有稍许区别。
    5.4.1客户登陆验证
    HTTP POST
    /api/v1/provider/login
    请求的body:
    field type
    appType string RETAIL 必填
    loginType string 登录类型,pwd,token或sms 必填
    userId string FinoChat ID或客户ID,loginType为pwd时提供 可选
    password string 密码(loginType为pwd时提供) 可选
    token string 令牌(loginType为token时提供) 可选
    mobile string 手机号(loginType为sms时提供) 可选
    verification string 验证码(loginType为sms时提供) 可选
    accountType string 账户类型,可选device(游客)或register(注册账户) 必填
    deviceId string 设备ID(移动设备唯一ID) 可选
    机构需返回如下格式的数据:

    {
        "userId": "",                // 用户的ID
        "data":{                     // 机构自定义返回的字段
            "account_type": "",      
            "level": "",
            "id": "",
            "loginType": ""
        }
    }
    

    5.4.2员工登陆验证

    HTTP POST
    /api/v1/provider/login
    请求的body:
    field type
    appType string STAFF 必填
    loginType string 登录类型,pwd,token或sms 必填
    userId string FinoChat ID或客户ID,loginType为pwd时提供 可选
    password string 密码(loginType为pwd时提供) 可选
    token string 令牌(loginType为token时提供) 可选
    mobile string 手机号(loginType为sms时提供) 可选
    verification string 验证码(loginType为sms时提供) 可选
    accountType string 账户类型,可选device(游客)或register(注册账户) 可选
    deviceId string 设备ID(移动设备唯一ID) 可选
    机构需返回如下格式的数据:

    {
        "userId": "",                // 用户的ID
        "data":{                     // 机构自定义返回的字段
            "account_type": "",      
            "level": "",
            "id": "",
            "loginType": ""
        }
    }
    

    5.5关系链

    5.5.1获取用户通讯录列表
    HTTP GET
    /api/v1/fsc/users/:fcid/contacts
    field type
    fcid string finochat ID 必填
    机构需返回如下格式的数据:

    [
         {
             "type": "customer",
             "onclick": "fold",       // 折叠展开
             "icon": "http://xxx.png",
             "name": "我的客户",
             "submenu": {
                 "name": "客户管理",
                 "icon": "http://xxx.png",
                 "url": "http://localhost/x.html"
             }
         },
         {
             "type": "securities",
             "onclick": "window",     // 新建窗口并展示数据
             "icon": "http://xxx.png",
             "name": "行业通讯录"
         },
         {
             "type": "branches",
             "icon": "http://xxx.png",
             "onclick": "href",       // 跳转到H5页面
             "url": "http://localhost/x.html",
             "name": "我的组织"
         }
    ]
    

    5.5.2获取通讯录结构

    HTTP GET
    /api/v1/fsc/users/:fcid/contacts/:contactType
    field type
    fcid string finochat ID 必填
    contactType string 通讯录类型(customer, securities, branches等) 必填

    机构需返回如下格式的数据:

    {
         "branches": [                // 若无数据,返回空数组
             {
                 "id": "branch_1",    // 全局唯一id
                 "onclick": "fold",   // 折叠展开 
                 "icon": "http://xxx.png",
                 "name": "凡泰极客"
             },
             {
                 "id": "branch_2",    // 全局唯一id
                 "onclick": "window", // 新建窗口并展示数据 
                 "icon": "http://xxx.png",
                 "name": "测试中心"
             },
             {
                 "id": "branch_3",    // 全局唯一id
                 "onclick": "href",   // 跳转到H5页面
                 "url": "http://localhost/x.html",
                 "icon": "http://xxx.png",
                 "name": "研发中心"
             },
             {
                 "id": "branch_4",   // 全局唯一id
                 "onclick": "room",   // 跳转到聊天房间
                 "roomId": "!QWEdeg1345dFFEF:finolabs.club",
                 "icon": "http://xxx.png",
                 "name": "测试中心"
             }
         ],
         "users": [{                  // 若无数据,返回空数组
             "fcid": "@alice:finogeeks.club",
             "state": 0,              // 用户状态,0表示正常
             "name": "爱丽丝",
             "avatar": ""
         }]
    }
    

    5.5.3获取通讯详情

    HTTP GET
    /api/v1/fsc/users/:fcid/contacts/:contactType/:id
    Field Type Description
    fcid String Finochat ID 必填
    contactType String 通讯录类型 必填
    id String 分支结构ID 必填
    机构需返回如下格式的数据:

    {
         "branches": [{
             "id": "branch_3",
             "onclick": "fold",
             "icon": "http://xxx.png",
             "name": "研发中心"
         }],
         "users": [{
             "fcid": "@alice:finogeeks.club",
             "state": 0,              // 用户状态,0表示正常
             "name": "爱丽丝",
             "avatar": ""
         }]
    }
    

    5.5.4搜索用户

    HTTP GET
    /api/v1/fsc/local/search?arg=xxx&contactType=branches&myid=xxx
    Field Type Description
    arg String 搜索参数 必填
    contactType String branches搜索员工,customer搜索客户,可选字段 可选
    contactId String 部门ID,可选字段 可选
    myid String 接口调用方的Finochat ID,可选字段 可选

    机构需返回如下格式数据:

    [
       {
           "fcid": "@alice:finogeeks.club",
           "name": "爱丽丝",
           "avatar": ""
       }
    ]
    

    6.运维及应急手册
    见于附件:《服务日常运维手册.xlsx》

    posted in 金易联
  • Swan Product Api

    增值产品对接接口文档

    api校验

    通过校验的形式确定接入用户的合法性、身份、权限,以及保证请求本身没有被中间篡改。当用户使用API时,应首先向凡泰极客申请api key和api secret

    请求公共参数

    每个调用API请求都必须包含以下公共参数,无论POST还是GET,公共参数都放在url里面以“query string"的方式请求

    参数名 说明 示例
    key api key,唯一代表一个用户的身份 2762aee5-4fa8-437e-85af-1dbfbe466298
    ts 请求的时间戳,格式为ISO8601格式,精确到毫秒。如果不带时区,默认为+0800,即北京时间 2015-08-29T12:31:24.556
    nonce 请求随机字符串,用于保证即便同样的请求,每次产生的签名都不同。``用户应保证每次产生一个随机字符串. 最短8字符,最长32字符。 zXwagyl3ksf
    sigVer 签名算法版本,目前只支持“1” 1
    sig 请求签名,产生方式详见下面 heBO3tbI1FHfhvt5x5cpswMlsCE=

    header通用参数

    所有请求的header里面需要添加X-Consumer-Custom-ID参数,参数值为调用接口的用户id,具体值可以询问凡泰极客

    请求签名如何使用

    签名的使用方式是:

    1. 在请求被发送前根据请求数据和api secret产生一个密钥,并作为请求参数sig的值。sig将会和其他参数一起发给服务器;
    2. 服务器端收到请求后,根据请求数据和内部保存的api secret重新计算一个签名,并将其与请求中sig参数值比较,以决定该请求是否合法。

    步骤1 将所有参数排序和拼接

    将请求中query string和body中所有参数放到一起,按照参数名字典升序排序,以"参数名=参数值"格式拼接每一个参数,最后将所有参数用"&"拼接到一起。 这些拼接到一起的参数包括所有公共参数和api特定的参数

    所谓 按照参数名字典升序排序,举个例子:
    假设有一系列参数的key和value: key2=v2&key1=v1&key4=v4&key3=v3
    参数名字是:key2, key1, key4, key3
    按照字典序排序后是:key1, key2, key3, key4
    排序,然后拼接的参数字符串则是: key1=v1&key2=v2&key3=v3&key4=v4
    

    注意:如果参数的值为空,则该参数不参与拼接和计算。

    步骤2 产生签名

    将步骤1的结果根据api secret产生一个HMAC Sha1摘要(注意:摘要应为2进制格式),并且以Base64编码产生签名. 将步骤1的结果传入HMAC Sha1 进行计算时,要对字符串进行UTF8编码。Mac和部分Linux操作系统默认会采用UTF8编码,所以开发时无需特别指定;但如果是Windows中文版,则会采用GBK编码。在这种情况下,需要在您使用的开发平台上明确指定使用UTF8进行sig的生成。

    sig = base64HmacSha1(apiSecret, encode(unifiedString, 'utf-8'))
    

    接口文档

    增值产品接口

    1. 新增增值产品

    {POST} /api/v1/open/adviserZone/forward/category
    
    RequestBody
    字段 类型 描述
    name string 名称
    picture string 图片
    desc string 描述
    link string 链接
    resourceId string 增值产品原id,用户平台的id
    sucess
    HTTP/1.1 200
    

    2. 增值产品列表

    {GET} /api/v1/open/adviserZone/forward/category
    
    QueryParam
    字段 类型 描述
    available 【可选】 Boolean 名称
    status 【可选】 number 状态 (0, "未上架"),(1, "审核中"),(2, "已拒绝"),(3, "已上架")
    page 【可选】 number 分页号码,默认0
    size 【可选】 number 分页大小,默认10
    sucess
    {
        "content": [
            {
                "id": "5ec38c6d501c0400012bc03f",
                "name": "sunhuiT2", 
                "order": 9, //顺序
                "creator": "@staff_super_M00000:111111.finogeeks.com",
                "creatorName": "超级管理员",
                "updater": "@staff_super_M00000:111111.finogeeks.com",
                "updaterName": "超级管理员",
                "createAt": 1589873773104,
                "updateAt": 1590034636382,
                "tid": "111111.finogeeks.com",
                "mid": "M00000",
                "articleNo": 0,  //文章数量
                "forwardNo": 0,  //转发数量
                "shareNo": 0,   //分享数量
                "viewNo": 0,    //查看数量
                "likeNo": 0,   //点赞数量
                "visitorNo": 0,  //查看
                "available": true,
                "status": 3,
                "groupIds": [  //权限组织
                    "49049240-e0f0-11e9-ac8b-bb3b44d95466",
                ],
                "picture": "https://res.wx.qq.com/wxdoc/dist/assets/img/0.4cb08bb4.jpg",
                "desc": "hello world",
                "link": "https://www.baidu.com",
                "resourceId":"123"
            },
            {
                "id": "5ec35180a7d1c70001a2fcaa",
                "name": "staff1-t",
                "order": 12,
                "creator": "@staff_super_M00000:111111.finogeeks.com",
                "creatorName": "超级管理员",
                "updater": "@staff_super_M00000:111111.finogeeks.com",
                "updaterName": "超级管理员",
                "createAt": 1589858688036,
                "updateAt": 1590041553782,
                "tid": "111111.finogeeks.com",
                "mid": "M00000",
                "articleNo": 0,
                "forwardNo": 0,
                "shareNo": 0,
                "viewNo": 0,
                "likeNo": 0,
                "visitorNo": 0,
                "available": true,
                "status": 3,
                "groupIds": [
                    "49049240-e0f0-11e9-ac8b-bb3b44d95466",
                ],
                "picture": "https://res.wx.qq.com/wxdoc/dist/assets/img/0.4cb08bb4.jpg",
                "desc": "hello world",
                "link": "https://www.baidu.com"
            }
        ],
        "pageable": {
            "sort": {
                "sorted": false,
                "unsorted": true
            },
            "pageSize": 10,
            "pageNumber": 0,
            "offset": 0,
            "unpaged": false,
            "paged": true
        },
        "totalElements": 10,
        "last": true,
        "totalPages": 1,
        "sort": {
            "sorted": false,
            "unsorted": true
        },
        "numberOfElements": 10,
        "first": true,
        "size": 10,
        "number": 0
    }
    

    3. 修改增值产品

    注意:修改增值产品需要先下架

    {PUT} /api/v1/open/adviserZone/forward/category/:id
    
    RequestBody
    字段 类型 描述
    name 【可选】 string 名称
    picture 【可选】 string 图片
    desc 【可选】 string 描述
    link 【可选】 string 链接
    order 【可选】 Int 顺序
    groupIds 【可选】 []string 权限组织id列表

    4. 删除增值产品

    {DELETE} /api/v1/open/adviserZone/forward/category/:id
    
    sucess
    HTTP/1.1 200
    

    5. 增值产品上下架

    {PUT} /api/v1/open/adviserZone/forward/category/available
    
    字段 类型 描述
    categoryId String 名称
    available Boolean true 上架 false 下架
    sucess
    HTTP/1.1 200
    

    文章接口

    1. 新增文章

    {POST} /api/v1/open/adviserZone/forward/articles
    
    RequestBody
    字段 类型 描述
    categoryId String 增值产品id
    available Boolean 是否上架,华西固定为true
    originAuthor string 专家作者
    originAvatar string 专家头像
    originGroup string 专家组织
    link string 文章链接
    sourceId string 文章源Id
    type string 文章类型 : 观点文章 TIMELINE, 长文章 LONG, 转载文章 REPRINT, 行业文章 INDUSTRY,华西选择LONG
    Content Json [<br/> {<br/> "type": "RICH_TEXT",<br/> "data": {<br/> "rich": {<br/> "richText": "富文本内容",<br/> "cover": {<br/> "url": "https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1590473639104&di=769911b15d3e8c34fedebf59812e2098&imgtype=0&src=http%3A%2F%2Fi2.hdslb.com%2Fbfs%2Farchive%2F821e33991046355e89b9de5fe4a82c10707c9ebc.jpg",<br/> "width": 1080,<br/> "height": 297<br/> }<br/> }<br/> }<br/> }<br/> ]
    text string 文本内容
    title string 标题

    2. 编辑修改文章

    要先下架文章,才能编辑文章

    {PUT} /api/v1/open/adviserZone/forward/articles/:id 
    
    RequestBody
    字段 类型 描述
    categoryId String 增值产品id
    available Boolean 是否上架,华西固定为true
    originAuthor string 专家作者
    originAvatar string 专家头像
    originGroup string 专家组织
    link string 文章链接
    sourceId string 文章源Id
    type string 文章类型 : 观点文章 TIMELINE, 长文章 LONG, 转载文章 REPRINT, 行业文章 INDUSTRY,华西选择LONG
    Content Json [<br/> {<br/> "type": "RICH_TEXT",<br/> "data": {<br/> "rich": {<br/> "richText": "富文本内容",<br/> "cover": {<br/> "url": "https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1590473639104&di=769911b15d3e8c34fedebf59812e2098&imgtype=0&src=http%3A%2F%2Fi2.hdslb.com%2Fbfs%2Farchive%2F821e33991046355e89b9de5fe4a82c10707c9ebc.jpg",<br/> "width": 1080,<br/> "height": 297<br/> }<br/> }<br/> }<br/> }<br/> ]
    text string 文本内容
    title string 标题

    3. 文章上下架

    {PUT} /api/v1/open/adviserZone/forward/articles/available
    
    RequestBody
    字段 类型 描述
    articleIds []String 多个文章id
    available Boolean true 上架 false 下架
    sucess
    HTTP/1.1 200
    

    4. 获取文章列表

    {GET} /api/v1/open/adviserZone/forward/articles 
    
    sucess
    {
        "content": [
            {
                "tid": "000000.finogeeks.com",
                "mid": "M00000",
                "id": "5d6d00dc974e6e00013e6508",
                "adviserId": "@staff_super:000000.finogeeks.com",
                "title": "普通的富文本文章",
                "contents": [
                    {
                        "type": "RICH_TEXT",
                        "data": {
                            "rich": {
                                "richText": "",
                                "cover": {
                                    "url": "5d6d00d9d20c160001090040",
                                    "width": 488,
                                    "height": 201
                                }
                            }
                        }
                    }
                ],
                "text": "体育消费政策加码 国资划转社保提速",
                "readNo": 615,
                "status": 3,
                "createAt": 1567424732010,
                "keywords": [
                    "股票",
                    "基金",
                    "股权"
                ],
                "originAuthor": "",
                "type": "LONG",
                "articleId": "AR1909021945328800001",
                "categoryId": "5ecc9ffa03c4940001c7a9d4",
                "recommend": true,
                "available": true,
                "auditor": "@staff_super_M00000:000000.finogeeks.com",
                "auditTime": 1590496850491,
                "referNo": 3,
                "shareNo": 2,
                "likeNo": 0,
                "updater": "@staff_super_M00000:000000.finogeeks.com",
                "updateAt": 1590496828734,
                "version": 2,
                "categoryName": "TD",
                "creatorName": "超级管理员",
                "updaterName": "超级管理员",
                "auditorName": "超级管理员",
                "visitorNo": 191
            }
        ],
        "pageable": {
            "sort": {
                "sorted": false,
                "unsorted": true
            },
            "pageSize": 20,
            "pageNumber": 0,
            "offset": 0,
            "unpaged": false,
            "paged": true
        },
        "totalElements": 551,
        "last": false,
        "totalPages": 28,
        "sort": {
            "sorted": false,
            "unsorted": true
        },
        "numberOfElements": 20,
        "first": true,
        "size": 20,
        "number": 0
    }
    

    5. 删除文章

    删除文章之前,需要先调接口将文章下架

    {DELETE} /api/v1/open/adviserZone/forward/articles/:id
    
    sucess
    HTTP/1.1 200
    
    posted in 金易联
  • 凡泰小程序平台运营相关FAQ

    1、凡泰小程序开放平台忘记了帐号密码,该如何找回?

    适用于已认证企业,如需找回登录邮箱,请相关开发者以“【凡泰小程序开放平台开发者帐号找回需求】”为邮件主题,邮件发送至contact@finogeeks.com,并提交以下材料,我们将尽快进行评估处理。

    • 1、注册主体的主体信息及主体营业执照、组织机构代码证等资质证明材料;
    • 2、注册主体的身份证姓名、身份证号码及手持身份证照片
    • 3、主体在凡泰小程序开放平台帐号下绑定的任一小程序的名称

    温馨提示:资质证明材料等须加盖公章。

    2、提交的小程序没能通过审核?

    • 1 、检查小程序提供的内容信息是否包含违反国家法律法规、违反公序良俗或侵害第三方权益的信息。
    • 2、检查小程序的名称、icon、简介、描述等信息是否含有政治敏感、色情、暴力血腥、恐怖内容及国家法律法规禁止的其他违法内容。
    • 3、检查小程序是否含有传播骚扰信息、恶意营销、虚假宣传和垃圾信息等

    3、超级管理员可以修改成员的登陆邮箱吗?

    目前暂时不支持修改管理员的登陆邮箱,只能修改姓名、用户名、身份证号,如成员登陆邮箱不可用或者遗忘,可重新添加成员管理权限

    4、一个企业最多可以添加几个管理员

    目前添加管理员这个没有做限制,看您自己的需求即可

    5、创建后的小程序支持改名吗?

    支持的,小程序在创建之后,小程序名称、小程序用途、小程序简介、小程序LOGO、小程序描述都可以进行修改,修改之后需重新审核。

    6、凡泰助手在哪里下载

    开发者可通过链接进行下载「凡泰助手」

    7、在平台后台可查看哪些数据指标?

    后台可查看创建小程序的打开趋势和次数,同时也可以查看小程序的访问设备占比

    posted in 小程序开放平台
  • 决战下半场:小程序技术助力金融APP重回C位

    内容共计6300字,预计阅读时间需要花费10分钟,您也可收藏后再进行阅读

    本文不是一篇纯技术文章,想与IT、电商、互金、网金以及负责数字化运营的部门同侪们一起探讨一下App的数字化建设。

    你们家的App是不是越来越“重”?

    银行、证券业机构在智能手机上发展App,到今年应该说有十年时间了。

    这十年来,相信很多机构的App都经历过数次的“伤筋动骨”的大改造。开始的时候外购了一些技术,然后让开发商在上面订制、修修补补,但是发现无法响应市场变化、业务创新需求、监管规则变化,于是要么是购买源代码、组建自己的研发团队接手彻底自研,要么是另起炉灶采用新的技术框架重新开发。相信很多机构都经历过维持旧的App还是自建新App的困扰、以及同时运营和维护两个甚至更多历史遗留App的痛苦。

    即便是好不容易稳定在一个比较干净利索的架构上,随着功能的不断堆叠、不同阶段的开发人员的不断接手改造,很有可能越来越复杂、越来越笨重,例如个别工程师的技术水平导致了App里的模块划分不清晰、功能高度耦合,最后导致改什么东西都可能“牵一发而动全身”;更糟糕的是,有些部分的代码在负责人员离开后,可能谁都不愿意或者不敢碰,逐渐变成App里的一个黑箱所在。

    App功能随着时间的积累而越堆越多,开发团队人员也进进出出,App变得越来越“脆弱”,每次发版的时间更长、需要回归测试的功能点更多。随之而来的是“敏捷迭代”名存实亡。开发团队在开发新功能、填补安全漏洞、实现监管机构所需的一些合规要求、救火被客户投诉的应用功能之间疲于奔命。

    创新变得越来越难。

    现有的技术能让App变“轻”吗?

    先稍稍回顾一下App技术历史的轨迹。

    古时候,开发App大家要养两个团队 – 一支负责iPhone版本、一支负责Android版本。这两拨人具备的知识结构、采用的编程语言、掌握的技术概念都是不兼容的。产品经理想实现同一个业务功能,必须跟这两拨人都说一次。并且,两个阵营的版本功能经常性不同步。这种类型的App叫做Native App(原生应用)

    后来,开始有人琢磨,我能不能让业务逻辑代码只开发一次而无缝跑在iPhone和Android两个世界呢?于是开始发明出用HTML5开发应用页面,通过“反向代理、远程加载、本地渲染”的办法进行运行,并通过一种叫JS Bridge的“桥接”技术对接到手机上的原生代码,这种类型的App叫做Hybrid App(混合型应用)。开始的时候这类应用性能不大好,但经过多年的优化(尤其是在Android上对浏览器内核的优化)以及手机硬件的升级,性能也总体得到提高。到今天为止,大部分的金融类应用估计属于这个类型。但是采用这种方案,我们还是得养着iOS和Android“两套班子”,分别负责各自平台上的一些原生部分的工作。

    再后来,Facebook也开始琢磨这事情 。“要让开发人员用类似JavaScript的语法,写出接近原生的性能效果”、“要让企业只养一套班子” - 于是Facebook发明了一种技术叫React Native,简称RN。市场上有越来越多的企业采用,开始的时候坑不少,经过多年的磨练,现在的RN也填了不少的坑。在金融领域,也有一些采用者。

    近年来,Google也在琢磨这事情。“要让开发人员学习Dart这种更牛逼的语言,写出高性能的App”、“要让企业只养一套班子”、“要让同样的代码牛逼到不仅仅跑在iPhone和Android上,还可以跑在个人电脑上” – 于是Google发明了一种技术叫Flutter。市场上也开始有越来越多的企业采用,当然,作为新生事物,坑还不少。在金融业,有没有机构在开始采用?可能还没有,或者有也是极少数。

    无论如何,开发App的技术是在进步的,起码在这三个方面:

    1)越来越不需要养“两套班子”了,节省人力成本

    2)开发门槛低了些,起码在iOS上,掌握Objective-C这种古代语言不是一种那么令人愉快的事情。同样的功能用Objective-C和Java分别在iOS和Android上实现一次,还无法保障它们运行起来是否表现一致。现在业务逻辑用JavaScript或者语法与JavaScript有相似性的Dart,开发一次,在两种移动端都可以运行,确实便利

    3)业务逻辑可以“热更新”了。想一想每次修个小bug也要对整个App重新编译、打包、回归测试、向各应用商店申请上架、等上几天才获得批准,甚至有被驳回的危险,这个过程多痛苦?绕开应用市场(尤其是苹果商店)让一些业务逻辑的代码能被App自身进行远程加载更新,对于经常有业务或监管需求不得不紧急迭代升级的金融机构来说,是非常必要的

    可是,上述这些技术,有让我们的App变“轻”吗?恐怕不见得。

    无论手机银行还是手机证券类App,实质上都是银行、券商放在用户手里的移动门户,一个App后面对接着很多的业务、很多的部门、很多的场景、很多的金融产品类别,这些东西只要耦合在App上,无法由不同的团队、按不同的时间节奏相对自由的发布到App中,这个App就无法真正的“轻”起来。

    就会导致牵一发动全身、就需要整个App的回归测试;开发模式上,就需要有项目经理、产品经理去协调企业内各部门的需求,排优先级,把功能实现排个优先级,进入App开发团队那资源有限的管道中排队。

    领导说,App是我们的“金融科技”(虽然并不是),必须全面投入,给你100个工程师… 可是这100号人估计大部分坐冷板凳,因为现有的技术架构没办法让你把人并行的用起来。

    金融类App的特点

    很多金融机构都有1到多个所谓的“C端”,以及1到多个所谓的“B”端。前者是在移动互联网发展早期导致的,可能是不同的业务部门各有想法、各自发展,逐渐形成了多个承载不同业务线的App;有些情况下,也出现不同厂家为其提供的、商业目的一样的、内部竞争的App – 券商里存在这种情况的不在少数。

    后者则往往是因为缺乏企业级的统筹,一会儿是建设一个赋能零售人员的移动应用,一会儿是采购一个解决远程办公问题的移动OA,一会儿是公司引入了某个CRM的移动版… 总之到了后来,出现五花八门的各种App,让员工们装上一堆,这些App在同一个手机里却泾渭分明互不相通,坚决形成信息孤岛,让使用者不得不来回切换,最终大部分的App都玩不起来。例如某大型银行提供给员工的App就不下十数个,占据其一个手机屏幕,光是从大同小异的图标来判断该用哪个干什么事情,就面临选择困难症。

    金融类App,其实天然有以下的特点:

    都是“赋能型”的,不是向客户提供各种功能供其在App里针对不同的业务进行自助服务,就是向员工提供各种工具供其进行营销展业、办公、汇报、查看报表等等。无论是C端还是B端,本质上都是一个前端集成的“移动端门户”- 镶嵌着各种工具、服务入口。工具之间从业务角度、功能角度看,并没有太多的耦合关系,它们为了处理不同的事情、面向不同的场景、由不同的部门负责。大家不过是在移动端分别埋些“模块”、“入口”而已

    迭代升级的诉求明显。对于C端来说,它需要的是一个灵活多变、有强烈的“可运营性”、便于创新的能力,并且因为金融市场本身的敏感性,任何时候在App端出现技术缺陷、信息安全问题、技术稳定性问题、资讯内容问题,金融机构必须有能力“实时”的进行处理,否则面临监管问责、客户投诉、经济损失。对于B端来说,它需要的是一个可以持续不断发布新赋能工具的能力,快速响应企业内部领导、业务部门、经营管理人员及一线员工的各种诉求 – 想到就做、做好就上、有反馈就优化。通常在公司内部推广一个新App并不容易,而废弃失败的可能性却很高。要让B端App有生命力,需要很多技巧,其中一个,必定是向全员展示不断推出新功能、快速响应使用者反馈的能力,呈现出“论持久战”的决心而不是给员工传递一个“玩票”性质的感觉

    对是否采用所谓“原生”(Native)的技术来开发应用,并不是非常重要。和手机游戏、办公套件(例如Microsoft Office)、即时通讯工具等等相比,金融类App的界面其实都是表单为主。其实用HTML5开发是合适的,至于RN、Flutter等技术,对于金融机构的开发人员,有新的学习成本,尤其是采用Flutter的学习曲线并不平滑(需要掌握一门新的语言,以及适应一个新的编程模型)

    可以这么说,很多银行、证券、保险的App,都是碎片化功能的“集散地”,最理想的方案是,各个“碎片”单独研发、测试、灰度发布,有独立的生命周期,运行在App这个“宿主”上但是无法影响“宿主”的稳定性、安全性。

    大道至简

    “碎片化”和“宿主”- 有没有这样的应用架构可以借鉴?当然有,而且是大家都熟悉的,就是微信。

    微信App,本身较为纯粹,功能设计非常克制,遵循着较为简约主义的设计逻辑(当然,这要看跟谁比,在海外市场里,Whatsapp可能是一个更加纯粹、功能聚焦、目标单一的IM),但是在它上面运行着数以百万计的小程序。这些小程序就是场景化、功能化的“碎片”,使用者随需随用、用完即走。而微信本身,就是支撑这些“碎片”运行的“宿主”(宿主这个比喻,也许不是最恰当,但是它就是让小程序们寄生在其中,并且可以通过分享、转发进行传播)。

    小程序的性能缺陷不能影响微信App本身、小程序的安全漏洞也理论上不能导致微信本身的信息安全问题,成千上万小程序由不同的机构拥有、开发者开发,它们的升级迭代也从来不影响微信App自身的稳定性。微信App本身在应用市场的发版更新,也同样不影响各种小程序的存在。微信App与运行在其中的小程序们,各自的生命周期独立、彼此耦合关系非常松散。

    在微信App内部,可以理解为两个基础技术的结合,一个是即时通讯 – 提供了交流、通讯、社交的功能;一个是小程序的运行引擎,提供了远程加载小程序代码并把它运行在安全沙箱里呈现给用户的能力。

    金融类App,能否整理出一个稳定的“内核”,作为“宿主”去运行、分享、传播各种变化频繁、敏捷迭代的功能碎片?

    金融类App是时候考虑新的架构

    基于金融类App的特点,“宿主”+ ”碎片”的架构是非常适合的:

    首先,金融类App如手机证券软件,非常强调稳定性,如果能保持一个已经在生产环境打磨过多年的App“内核”,则是最为理想的。这个“内核”仅以原生(native)方式实现最关键、最需要稳定的行情与交易相关基础功能,轻易不作改动。在当下的股市,能扛的住黑天鹅事件频发的所引起的突发性客流量、交易量,需要一个稳定、可靠的交易核心,也就是说,把App本身也分成券商IT们喜欢说的“稳态”和“敏态”。

    其次,大部分的业务功能,以“碎片”的方式实现,拥有完全独立的生命周期,独立于App之外进行开发、测试、灰度发布。“碎片”最理想的技术载体,是类似“微信小程序”那样的形式。想象业务功能点以小程序开发,经过IT内测、业务部门UAT、合规审核、运维上架,整个发布流程完全数字化、在线。发布之后,依然通过灰度控制,让该业务功能小程序在有限人群范围逐渐放开,这一切在App侧是无感的,万一有问题,可以瞬间下架。

    第三,兼容微信小程序的“标准”。开发人员只要懂微信平台上的小程序规范与框架,就能够开发。这样,在市场上能找到大量的技术人员,从大学毕业生到有经验的工程师,人才资源更加丰富。当前百度、阿里、美团、京东、字节跳动等互联网大厂均有类似于微信小程序的技术,但是无论哪家厂都不得不接受有巨大先发优势的微信小程序作为“既成事实”的开发标准。虽然我们可以基于Flutter、RN等技术重新发明“碎片化”的技术载体,可是市场上有无大量可驾驭这些技术且成本较低的人才也是我们在设计技术方案时需要关注的。

    第四,金融机构(券商、银行、保险、基金等)自己扮演了腾讯的角色,在自己的机房运行自己的小程序中心,让内部的工程师、外部的外包商技术人员、合作伙伴的IT都可以申请获得“开发者账户”,申请把自己开发的小程序进行上架和灰度发布。这个能力一旦建立,金融机构各条业务线就有可能通过自己的IT团队或者临时招募的合同工程师,针对自己的业务场景开发小程序并申请上架到公司的App(也是面向所有客户的移动门店)。

    这有可能导致一种新的IT研发团队组织结构(例如小程序开发人员可能由“业务IT”负责,与App研发团队解耦)、一种更加DevOps友好的开发模式(结合PaaS和Serverless技术)。

    App从信息化到数字化的跳跃

    技术人员在评估选择App开发技术的时候,往往只考虑解决跨平台问题、热更新问题、开发语言问题、开发框架问题,在RN、WeeX、Flutter或原生与Hybrid型技术的选型之间纠结。但就金融这个领域来看,这些技术都只是底层的实现手段,它们是战术性、技巧性的、从信息化角度看的。着眼点还是提高内部开发效率、降低一点开发成本。这还是把App的实现看成是一个信息化过程,和20年前开发网站把企业内部的一些技术系统集成输出以便于客户在网上自服务,是一个思维。

    移动互联网改变了这个格局,带来了数字化时代。移动端App是数字化的开端。新一代金融类App,起码需要做到以下几点。

    具有传播能力。传播的不仅是信息,还有工具和场景。目前最普及、最容易为大众所接受的,就是小程序这种载体。想一下,现在连七八十岁的老人,都知道微信里的小程序这么个东西,知道用它打开健康码出入小区。子女替父母购买电商产品,把一个小程序转发过去,老人即可打开购物车看到是否自己要的东西。这种在终极用户层面的感知,不是RN、Flutter纯粹技术实现层面所能达到的。

    具有连接能力。平台型的App和纯工具型的App不同之处在于,前者天然具有社交属性,这也是移动互联网给我们带来的产物。当前无论银行、证券还是保险类的App,绝大部分缺乏平台思维,都是做成高度同质化的、客户自服务为导向的、工具型的东西,可是很多金融服务的性质天然决定它应该是平台型的,是对接多方 – 外部的客户、合作伙伴和内部的各种业务线及岗位职能。连接多方,让他们以共同的场景、上下文进行交流互动,是数字化的另一个要素。而小程序,刚好是能以场景化促进连接的技术载体。

    具有生态化能力。我们知道互联网巨头们逐渐形成了所谓的Super App(超级应用),它们手握公域流量,在自己的平台上让大量的第三方“进驻”,让自己的客户在一个Super App里获得所有的工具与服务,通过丰富的生态圈住了用户,同时也把合作伙伴牢牢绑住。金融业能否出现Super App,有不同的观点。但国内一些大型银行的App,显然是在尝试成为Super App,玩生态游戏。那么对中小型的金融机构是否就没有参考价值呢?显然不是,在数字化的世界,一切都是生态化的,无法想象这个时代我们哪家金融机构不需要外部的合作 – 资讯内容的提供商、新媒体的合作伙伴、理财产品的代销机构、专业培训机构… 通过一个强大的合规审核后台,把合作伙伴的小程序“上架”到自家的App,借力外部资源共同服务客户,是未来的一种可能。以保险公司为例,完全可以构建这么一个数字化生态平台,引入更多的合作伙伴服务客户,把一个个静态的“保险账户”变成“用户”。

    具有最简最优的用户体验。很多金融业务其实是低频的,不必期望所谓的用户黏着度、活跃度,在App里堆叠大量的功能,不见得有多好的投入产出比。通过推送高质量、个性化、为客户量身定制的资讯内容来吸引和转化用户,在他到来时则给他干净利落、简单好用的自服务功能,是一个更好的方向。

    越简单的应用实质上越强大,结合On-Device AI(端侧智能),App的操作界面是越来越简单越来越回归人类感官本能的。正如很多父母辈的老人,不要说驾驭不了PC,连打字机都从不曾触摸过;结果智能手机出现后却能熟练掌握以即时通讯工具进行社交,阅读分享新闻、进行电商购物。越来越结合人工智能的软件,界面只能进一步的简化,了解用户的画像、对用户的行为偏好有预测能力的AI,会把与App的人机交互复杂度降到最低。让用户通过一个极简主义的App“宿主”,获得智能算法推荐过来的各种“碎片化“功能(小程序),随需随用,用完即走,再也不需要在一个App的菜单和服务入口里层层深入的去定位一些功能。

    凡泰极客希望把迄今为止只有互联网巨头们才拥有的小程序技术能力,以“白牌”(white label)方式赋能给传统金融业

    我们把“小程序运行时”实现成一个可私有化部署的iOS和Android版本的SDK,任何金融机构的App均可以嵌入该组件而瞬间获得运行小程序的能力;同时也提供了“小程序开放平台”的解决方案,供任何金融机构、行业组织运行自己的小程序生态、统一上下架管理自己以及合作伙伴们的业务场景。

    与互联网巨头方案不一样的是,我们的方案不仅更加开放(提供API接口,支持二次开发),也更聚焦金融行业在合规监管方面的特殊行业诉求。目前已在多家银行、保险、证券以及相关行业机构落地,并能够自有机房内独立部署运行。不仅如此,“凡泰小程序技术”语法结构和微信小程序兼容,一次开发,多处上架,可降低开发成本,提升研发效率。

    凡泰小程序当前已经开放了一键部署功能,现可免费体验,只需5行代码30分钟,即可在您的应用内集成「小程序运行时」,点击【阅读原文】进入官网通过手机号即可完成注册体验

    如想了解更多关于“凡泰小程序技术”的方案,或者您有什么疑问?欢迎打开下方的小程序进行在线咨询

    0_1587086192089_二.png

    posted in 官方公告
  • 5000字解析:前端五种跨平台技术

    本文不涉及到任何代码,只讲概念层面的,结合本人在实际开发过程中的各种体验,对这几种跨平台技术进行一个点评。

    跨平台技术的由来

    传统的纯原生开发已经不能满足日益增长的业务需求。主要表现在如下两个方面。

    • 动态化内容需求增大。当需求发生变化时,纯原生应用需要通过版本升级来更新内容,但应用上架、审核是需要周期的,这个周期对高速变化的互联网时代来说是很难接受的,所以,对应用动态化 (不发版也可以更新应用内容) 的需求就变得迫在眉睫了。

    • 业务需求变化快,开发成本变大。由于原生开发一般都要维护 Android、iOS 两个开发团队,版本迭代时,无论人力成本还是测试成本都会变大。

    总结一下,纯原生开发主要面临动态化和开发成本两个问题,而针对这两个问题,又诞生了一些跨平台的动态化框架。

    跨平台技术简介

    针对原生开发面临的问题,人们一直都在努力寻找好的解决方案,然而时至今日,已经存在很多跨平台框架 (注意,本书中所指的“跨平台”若无特殊说明,即特指 Android 和 iOS 两个平台),根据其原理,主要可分为如下三类。

    1)H5(HTML5)+ 原生 ( Cordova、 Tonic、微信小程序)。

    1. Javascript 开发 + 原生渲染 ( React Native、Weex、快应用)。

    2. 自绘 U+ 原生 ( QT Mobile、 Flutter)。

    接下来,我们将逐个来了解这三类框架的原理及优缺点。

    1.12 Hybrid 技术简介

    H5+ 原生混合开发

    这类框架的主要原理是将 APP 需要动态变动的一部分内容通过 H5 来实现,通过原生的网页加载控件 Webview( Android) 或 WK Webview(iOS) 来加载 (以后若无特殊说明,本书将用 Webview 来统一指代 Android 和 iOS 中的网页加载控件)。这样,H5 部分就可以随时改变而不用发版,动态化需求得到满足 ; 同时,由于 H5 代码只需要一次开发,就能同时在 Android 和 iOS 两个平台上正常运行,这也可以降低开发成本,也就是说,H5 部分的功能越多,开发成本就越小。我们称这种 H5+ 原生的开发模式为混合开发,对于采用混合模式开发的 APP,我们称之为混合应用或 Hybrid APP,如果一个应用的大多数功能都是采用 H5 实现的话,我们称其为 Web APP。

    目前混合开发框架的典型代表有 Cordova、 lonic 和微信小程序,值得一提的是,微信小程序目前是在 Webview 中渲染的。并非原生渲染,但将来有可能会采用原生渲染。

    混合开发技术点

    如之前所述,原生开发可以访间平台的所有功能,而在混合开发中,H5 代码是运行在 Web View 中的, Webview 实质上就是一个浏览器器内核、其 script 依然运行在一个权限受限的沙箱中,所以对大多数系统能力都没有访向权限、如无法访向文件系统、不能使用蓝牙等,所以,对于 H5 不能实现的功能,都需要原生来实现。

    而混合框架一般都会在原生代码中预先实现一些访问系统能力的 API,然后暴露给 Webview 以供 Javascript 调用,这样一来, Webview 就成为 Javascript 与原生 AP 之间通信的桥梁,主要负责 Javascript 与原生之间调用消息的传递,而消息的传递必须遵守一个标准的协议,其规定了消息的格式与含义,我们将依赖于 Webview 的、用于在 Javascript 与原生之间通信并实现了某种消息传输协议的工具称为 Webview Javascript Bridge,简称 Jsbridge,它也是混合开发框架的核心.

    我所使用的跨平台技术:

    • Electron
    • React-Native
    • Taro
    • Cordova
    • 快应用
    • Flutter(刚学习)
      ...
      排名由前往后,除了 Flutter 没有使用过在商业项目中

    Electron 的核心:

    Electron 就是把 Node.js 的运行环境和谷歌浏览器内核一起打包了,于是就拥有了 Node.js 和 H5 技术的融合能力,又因为是基于 C++ 编写,于是可以跨平台。Mac、Windows、Linux。

    工具类的软件是最复杂的,例如 vscode、word 这些,都是极度复杂的,又因为可以调用 addon、各种脚本插件,原生第三方插件,这个技术简直就是黑科技,至今我也不敢说对它熟悉。但是 APP Store 已经不能上线 Electron 应用了,而且打包签名服务器也经常挂

    特别注意:Electron 开发出来的东西是软件,是一个安装在电脑上的软件!

    我的 GitHub 可能有你想要的 Demo 内容:

    https://github.com/JinJieTan

    要想开发好 Electron,要拥有一名 C++ 人员专门编写插件,一位后端出生的人生操作 sqlite 数据库(数据库升级虽然可以兼容老版本,但是复杂的应用设计得不好数据库就完了),一位前后端都懂并且熟悉调用操作系统插件的全栈工程师开发,这样才能 hold 得住复杂应用。如果你说这样是不是太浪费了,那我觉得你没有开发过复杂的软件,一个好的软件(客户端),要考虑程序反编译(保护)、奔溃守护进程等异常搜集、用户自动升级(差量 or 全量)、本地数据库加密、通信、激活唤醒。。。。太多了,但是大部分前端做的就是后台管理系统,这也是一个悲剧。。。面试造火箭像以前我就做过将微信和 QQ 里面一些插件拿出来经过一些处理用在项目里,至此打开了新世界, 总之 Electron 非常考验技术,是晋升伪全栈工程师最快的路径。

    推荐学习指数:五颗星

    React-native

    去年爱彼迎把 APP 的技术从 RN 换回了原生,首先它是外企,它可能某种程度上,使用 RN 会比国内有更大的优势,获得更大的支持。就像你使用 Taro,那么你有可能在论坛上找到它的负责人,提出想要的支持,最后它真的支持了(这个是存在的,如果你想认识可以帮你联系,我也在建议身边人使用 Taro)。

    回到正题:

    难道 RN 死了吗?

    JQuery 都没死,它会死吗?当然不会!RN 的生态非常强大,它开发出来的,也是真正的原生应用,它的原理如下:

    在 React-native 文件中编写的代码,会在内存中生成虚拟 DOM 对象(其实就是一个 JS 对象),然后再通过 javaScriptCore(IOS 自带,安卓不是,所以 RN 打包后安卓的包比苹果大) 映射成原生控件树。很多 jsBridge 都是基于 javaScriptCore 实现的。

    例如:

    0_1585536670500_f35c9173-f1ee-4206-9d83-4ac75449f8b5-image.png

    提示:跨平台不是什么高深的技术,只要搞懂它的运行机制原理,就好开发,定位问题。

    那么 RN 有什么缺点呢?例如频繁 setState,可能会造成卡顿(做动画的时候容易掉帧,特别是性能差的手机),但是也是可以使用一些技术优化尽量避免,跟是谁写的有很大关系,还有就是项目变得特别大,跟原生交互特别多,特别复杂的应用,跨平台遇到的问题兼容处理也会越来越多,这也是为什么爱彼迎会换回原生的原因,维护确实比较麻烦,还有版本环境的问题,有可能你升级了以后再也启动不了了。。。

    推荐理由:开发快速,生态成熟,使用 React 的 JSX 语法和 FLex 布局快速开发原生应用。

    推荐学习指数:四颗星

    Taro

    小程序跨平台开发,一款可以用 TSX、JSX 和 React 语法开发小程序的框架,内置了一些 UI 组件,还有物料市场,目前看势头很好。还可以集成 React-native, 真正做到一套代码多处运行,不仅能编译成各种平台小程序,还可以是 RN 的应用~ 666 , 还支持 快应用:

    https://taro.aotu.io/

    现如今市面上端的形态多种多样,Web、React-Native、微信小程序等各种端大行其道,当业务要求同时在不同的端都要求有所表现的时候,针对不同的端去编写多套代码的成本显然非常高,这时候只编写一套代码就能够适配到多端的能力就显得极为需要。

    使用 Taro,我们可以只书写一套代码,再通过 Taro 的编译工具,将源代码分别编译出可以在不同端(微信 / 百度 / 支付宝 / 字节跳动 /QQ/ 京东小程序、快应用、H5、React-Native 等)运行的代码。

    Taro 的源码我没看过,但是我看里面用了很多他们自己写的 babel 包,应该是 JIT 模式,加入了中间层,把你写的东西,编译成了小程序可以执行的代码,个人认为小程序不要做得太复杂,不然你还不如做个 APP,轻量跨平台,自然是最快速的,而且可以使用 TSX 语法,React,太好了。

    推荐指数:五颗星

    Cordova

    它是一个比较古老的技术,但是我目前的公司使用得比较 6,还做成了一套产业体系,我觉得它也挺不错的。

    它是比较传统的跨平台技术,类似小程序,在 webView 中渲染,原理如下:

    其实就是原生的 webView 去加载,执行 H5 代码,这样可以跨平台,而且可以随时更新发布内容。这就是传统的 hybrid APP (混合开发)。

    还有一种 webApp, 直接用 h5 的技术打包成 APP,比较简单,这个百度下就知道了。

    Hybrid 技术应该比较多,但是原理大同小异,都是通过 webView 加载,性能体验肯定没有原生好,因为调用 webView 需要几百毫秒的时间,但是也可以通过一些技术优化,跟谁写也有很大关系。

    快应用

    就是华为、小米等国内厂商为了跟小程序竞争搞出来的,像 RN 这些框架,回内置一些渲染 / 排版引擎,那么打包出来提交比较大,快应用是集成到安卓手机的 ROM 中,所以只有源码那部分,安装体积比较小,这样就叫快应用。

    快应用使用原生 js 开发,框架跟原生微信小程序很像(写着不舒服,Taro 支持快应用)。

    提示:写快应用的工资很高,感觉基本都在 30K 以上(可能是错觉)。

    Flutter

    Flutter 是 Google 推出并开源的移动应用开发框架,主要特点是跨平台、高保真、有些性能。开发者可以通过 Dart 语言开发 APP,一套代码可以同时运行在 iOS 和 Android 平台以上。Flutter 提供了丰富的组件、接口,开发者可以很快地为 Flutter 添加 Native 扩展。

    同时 Flutter 还可以使用 Native 引擎渲染视图,这无疑能为用户提供良好的体验。

    跨平台自绘引擎

    Flutter 与用于构建移动应用程序的其他大多数框架不同,因为 Flutter 既不使用 Webview,也不使用操作系统的原生控件。相反, Flutter 使用自己的高性能渲染引擎来绘制 Widget。这样不仅可以保证在 Android 和 iOS 上 UI 的一致性,而且可以避免因对原生控。

    件依赖而带来的限制及高昂的维护成本。

    Flutter 使用 ska 作为其 2D 渲染引擎,Skia 是 Google 的一个 2D 图形处理函数库,包含字形、坐标转换,以及点阵图,且都有高效能且简洁的表现,Skia 是跨平台的,并且其还提供了非常友好的 API,目前 Google Chrome 浏览器和 Android 均采用 Skia 作为其绘图引擎。目前, Flutter 默认支持 iOS、 Android、 Fuchsia( Google 新的自研操作系统) 三个移动平台。但 Flutter 亦可支持 Web 开发 ( Flutter for Web) 和 PC 开发。

    高性能

    Flutter 的高性能主要靠两点来保证,首先, Flutter APP 采用 Dart 语言开发。Dart 在 JT(即时编译) 模式下,速度与 Javascript 基本持平。同时 Dart 还支持 AOT,当以 AOT 模式运行时, Javascript 便远远追不上了。速度的提升对高帧率下的视图数据计算很有帮助。其次, Flutter 1 使用自己的渲染引擎来绘制 UI,布局数据等由 Dan 语言直接控制,所以在布局过程中不需要像 RN 那样要在 Javascript 和 Native 之间通信。

    这一点在一些滑动和拖动的场景下具有明显的优势,因为滑动和拖动的过程往往会引起布局发生变化,所以 Javascript 需要与 Native 不停地同步布局信息,这与在浏览器中要 Javascript 频繁操作 DOM 所带来的问题是相同的,都会带来比较可观的性能开销。

    重点:Flutter 自己有自己的渲染引擎,这样避免了以上几种跨平台技术的通过中间层通信带来的性能开销,但是依然避免不了写原生代码,而且目前 GitHub 上的 issue 还比较多,不过小编已经入坑了,就学最后一个,以后就不学前端了。

    Dart 语言学习也需要一些成本,如果公司有这个安排的话,可以入坑尝试。

    综上五种所述:不一样的业务场景有一样的技术场景,技术为产品服务,跨平台的出现并不是为了干掉原生,而是为了更好的、更高效的开发。

    作者 | Peter 谭金杰

    posted in 极客周刊
  • 开源商业模式促进金融业科技生态的发展

    《从高盛的技术“开源”看金融业软件发展未来》中,总结了一些传统金融机构IT研发所遇到的放不开手脚的问题,并提到金融行业是时候与时俱进的借鉴采纳开源科技公司的做法,借力打力。

    本文讨论一下开源的商业模式以及所能促进形成的金融科技业态。

    金融科技的新业态

    我认为让证券业、银行业以及其他金融细分领域做好科技金融,应该分工协作,形成良好的业态。

    首先是行业开发商,作为金融科技的输出机构,职责就是对持牌机构科技赋能,提供开放、开源的技术产品,通过开放接口、开放组件、开放源代码,让持牌机构的IT人员能做好二次开发、支持业务创新;并基于行业丰富的需求场景和案例,归纳、提炼、持续优化产品,常态性回馈给持牌机构,形成输出、反馈、再输出的闭环。行业应允许“生物多样性”,让各种初创公司聚焦自己细分领域的一些基础技术,例如消息中间件、即时通讯工具、CRM、风控组件等等,各自做到极致。

    而另一方面,开发商们把自己的领域做好做专,抓住一两个点服务全行业,也可以很好的生存,而不是什么东西都大包大揽、什么都干、杂乱无章的做出些三、四流的混淆视听的“竞品”(在招标的时候充当“添乱”的角色)。

    其次是持牌机构,不能空喊科技口号但一两个工程师也舍不得招聘,什么都依赖开发商去做,应鼓励科技团队选用行业技术提供商的开放技术做好二次开发、聚焦业务创新。此外,有能力的机构也可以像高盛那样,把一些内部研发的不涉及业务的底层技术(例如高盛开源了它的GS Collection,一个Java的数据结构实现框架)贡献给同业,让大家共同维护,延长它的生命力,也降低自己的投入成本。这也是当前行业非常需要的“协作竞争”。

    第三是行业自律组织、监管机构下属事业单位或者其他各种协会,完全可以在以开源技术促进行业科技发展方面做出重大的贡献。我们知道互联网上无数的开源技术,良莠不齐,来源复杂,对于金融行业这种信息安全、隐私保护非常敏感的强监管行业,有时候有必要通过一些公益性的组织来推动业内自己的开源技术发展,实现行业级的协作互助、制定行业标准。FinOS Foundation(金融科技开源基金会)是一个华尔街的非盈利组织,它的前身是Symphony Software Foundation(Symphony是一家前身脱胎于高盛内部LiveCurrent的即时通讯技术公司,由高盛、摩根大通、贝莱德、摩根斯坦利、美银美林、花旗、瑞银、野村等十几家金融机构联合投资),这个基金会并充当了行业与外部科技企业在开源协作方面的连接点,吸纳了RedHat(红帽)、GitHub等开源科技企业成为其白金成员。

    受监管机构认可的行业云服务商或类似FinOS基金会的独立非牟利组织,还可以为行业孵化一些开源项目,以及对话科技厂商,协调其发布有金融业针对性、特别安全加固、符合合规诉求的开源技术发行版(distro)。

    金融业的开源商业模式

    虽然在国内投资界,VC们青睐SaaS,但在金融业尤其是证券行业,云服务本身因信息安全、数据隐私保护的合规监管要求而受到很大的制约,券商、基金们总体来说还是以招标、采购软件、私有化部署为主,证券业可以说还没有可落地的SaaS。

    风投们对传统软件商业模式并不感冒,那么证券业的软件企业是不是就很不“sexy”?如果还是在走二十年前的封闭、垄断、欺压客户、销售靠喝酒吃饭拉关系的模式,每年收个服务支持费用,确实难怪风投们觉得无趣。

    但事实上新的软件商模式已经出现很久,有很多架设在开源技术上的成功商业案例,适合金融业里无法做SaaS的科技企业参考。以下是两大类型:

    基于公共的开源技术进行优化、维护,提供商业化的发行版(distro),并向企业提供技术支持。这类成功企业里远的有Redhat,2018年IBM以340亿美元收购。近的有Cloudera + Hortonworks,两家基于开源大数据技术Hadoop来做商业化产品及服务的公司,他们分别于2017年和2014年IPO,并在2019年合并。这类企业对所赖以生存的开源技术并没有控制权

    基于自己主导研发的开源技术核心,打造商业产品,有核心技术控制权。取得成功的包括Mulesoft,一家只做企业级应用软件间的数据互通的公司,被Salesforce以65亿美元收购;Elastic,一家帮助企业做数据检索的企业,其2018年9月上市前12个月的营收是1.6亿美元,至2018年末市值50亿美元;IT界家喻户晓的技术Kafka的拥有者Confluent,被称之为“开源独角兽”,于2019年初获得红杉资本领投的D轮1.25亿美元

    开源,是一种新的软件生产协作模式,它有以下的商业竞争优势:

    通过开源社区,吸引和利用优秀人才。最具前景、最有用的开源项目往往能吸引到最顶级工程师。这其实是一种“杠杆”的利用,也能促进开源产品在社区的快速迭代

    有助于获客。如上文所述,很多金融机构采购系统的时候也想获得源代码,这背后的逻辑是担心厂商封闭,让自己不能订制;以及对被某个技术“绑架”的防范 – 万一它忽然终止存在又无法被轻易替换,而分分钟和钱挂钩的业务系统却构建在它的基础之上,这个风险太大。处于敏感位置的基础技术,如即时通讯工具,其源代码开放可审计,也让一些机构对信息安全、数据隐私保护方面放心。开源在现在已经成为一种信心保障

    有助于建立商业生态。通过知识产权的开放,让客户以较低门槛采纳,逐渐形成市场规模,并形成社区、建立上下游的合作伙伴,有机会成为de facto standard(事实上的标准)。Kafka就是一个好例子,不知不觉中很多金融机构就已经采用了它,技术人员甚至以它的技术概念作为词汇表描述问题与方案

    但并不是说开源要替代闭源,例如含有金融业务逻辑的一些系统不见得有开源的必要,而支撑这类系统的底层“基础软件”,则非常适合考虑开源的模式。例如具备金融行业针对性、强金融合规属性、自证没有安全后门的即时通讯技术(是一般开源即时通讯技术所实现不了的),基于多年的债券交易业务理解抽象而设计出来的消息中间件(是RabbitMQ、ActiveMQ、QPid之类所无法满足的),或者因为对证券行业的了解而为证券机构量身定做、优化(填坑 – 没商业化的开源技术都很多坑)并加入了异地机房备份和合规留痕能力的开源大数据技术稳定发行版等等,这些都是对行业非常有价值的适合开源的技术。

    知识产权的保护

    开源并不是放弃知识产权,与传统商业软件的Copyright(著作权)不同,开源软件讲的是Copyleft(“著佐权”- 一个为自由软件运动而生造出来并进入了字典的英文字)和Permissive(宽松许可权)。这些许可证的存在,一方面不同程度的保障原作者的知识产权、另一方面也授予使用者比商业软件友好的条款。

    其中Copyleft类许可证,也被称为“病毒型”许可(非贬义,是指其对于采用者有知识产权的传播复制上的条件约束 – 即引用或修改了它的代码的软件也需以同种方式开源等等),对于既需要建立开源生态又需要商业化的企业,是非常有帮助的。最著名的两类是Eclipse开源许可证和鼎鼎大名的GNU GPL系列许可证。

    宽松许可证中,最典型最普遍被采用的是Apache 2.0、MIT和BSD。它们有助于一些技术更易于被广泛的利用和传播。

    目前国际上的开源促进会(OSI - Open Source Initiative)罗列了不下六七十种开源许可证。而我国最近也提交并获得OSI批准了第一个国际化开源许可证《木兰宽松许可证 v2》,该许可证用中英双语书写。可见我国的软件知识产权方面也发展到一个新的高度,值得金融业的IT人关注与利用。

    未来已来 - 是时候共同实践与探索

    但是金融业又是有其特殊性的,对开源技术的安全性、稳定性有着更高的要求,并不是任何技术都适合开源。如何找到开源与闭源恰当混合的策略,去避免一些核心的基础技术模块让公网上的开源社区植入恶意代码,同时又能安全的与持牌机构共享一些知识产权?值得去深入探索。

    我们就是一家向金融机构和监管机构提供具通用金融属性的基础技术的科技公司。例如我们的即时通讯技术针对的是金融零售服务、投行业务、研究所业务、合规监管场景、交易场景的基础层诉求,有别于互联网通用的即时通讯技术。所谓“术业有专攻”,我们在即时通讯技术这个领域有多年的深入研究,从加密技术、联邦式互通、区块链上的IM应用、到国际上金融与非金融行业社交技术竞品的分析,结合对金融业务场景的了解,想法不断,所积累的认知与创意,只想说“当仁不让”。我们希望运用开源与闭源混合策略与恰当的开源许可证,向行业提供能充分满足金融业务需求的、高度可定制的、灵活的即时通讯技术,同时越多的机构向我们提出越丰富的场景,我们越能持续优化这个技术并回馈行业。

    行业机构“众筹”了科技企业的一些基础技术项目,而科技企业做好自己擅长的事情并与“赞助者”们共享了成果,相信这是金融行业科技发展的一个良性循环。

    关于金融科技领域的开源,您有什么想法?欢迎打开下面的小程序访问本人的个人工作室进行交流。

    作者:梁启鸿

    0_1587086215247_二.png

    posted in 官方公告