1. 又重新看了下邮件 发现自己还是有很多地方没有记住
权限部分基本上忘的干不多了.
记得GScloud权限的的核心是使用RBAC
权限又细分为 操作权限和数据权限
操作权限主要针对 动作 菜单打开 以及菜单上面的按钮等
数据权限主要针对 数据操作中的对象
还可以在BE中设置去权限字段,这样的话就可以直接使用权限字段进行权限分配
2. 功能菜单依托于BE和权限的实体(没记住)
通过发布到框架作为打开功能使用.
3. 还讲了一些命名规范,以及简单使用也讲了UDT的使用
用户自定义的类型,现在支持简单类型和复杂类型 也支持枚举等(就是 mapping暂时不支持的部分)
4.总体来说 基于微服务的 GScloud 的开发 现阶段使用文件交付. 升级的话 需要 手工覆盖部分应用端的文件,以及手工升级pgsql 或者是 拉取数据 用来迁移,
发布之后 应该是可以在 windows linux 以及 docker下面进行安装部署
理论上最细维度 可以一个su 一个docker 通过k8s 进行编排 服务发现 以及通过每个su内部 框架的 agent 进行交互. 来最大化开发效率.
所有的交互 都是RPC或者是 restful的交互.
前端开发与后端开发 完全分层,前端开发 也是分层的 表单和数据 完全分离,这样的话 能够最大化 需求变更时的开发效率, 做到 write less do more
后端技术栈 以 dotnetcore 为主,但是兼容支持 java 和 nodejs 等.
前端技术 以angularJS为主. 使用npm解决这种依赖关系 使用webpack 进行打包等处理.
5. 平台不仅仅会提供这一套开发内容, 还应该提供 支撑这一套 运维支撑体系还有 监控体系
运维支撑体系 应该是类似于 registry repository 的仓库概念 能够支持 将 最新的artifact 发布到 repostory中,然后通过k8s 定义的 service 或者是pod的 policy 以灰度或者是金丝雀模式发布.
这里面 CI/CD 应该是使用TFS 或者是gitlab/jenkins 来支撑 自动化测试 必须做到足够细粒度话来最大化产品质量保证.
监控体系也很重要 如果纯docker化部署 docker又是无状态的 也不能 通过写log的方式来进行调试, 只能通过elk 体系 kibana的方式来查看日志 进行调试.
以及 使用 prometheus和 grafana 的工具进行运维监控, 以及 使用类似于 istio的方式 实现 服务的熔断降级等处理.
su 之间的信息交互以及 类似于消息队列的处理 以及 event bus 都是很基础很核心的内容,需要保证性能和不丢消息才能做到 最大化的性能
----------------------
以后继续补充