框架起源
框架起源
警告
因为服务器迁移,本站随时会中断https服务,请使用http请求本站,谢谢.
从业十多年以来,虽然一直都在积累,内容相对比较多,但是始终处于一个比较混乱的状态.启路框架作为我从业十多年的经验的积累,做一个完整的技术输出.现阶段服务器的应用主要分为如下几类:
| 类型 | 说明 | 系统特征 |
|---|---|---|
| 互联网直接访问的应用 | 主要是以前的各种站点,主要给客户使用 | 框架+安全+页面1 |
| 没有页面的中间服务 | 传说中的微服务的原子服务,没有页面 | 框架+通讯 |
| 后台管理类应用 | 有页面,但是主要是给雇员使用 | 框架+安全+页面2 |
内管页面的安全,要面对的是内网环境,主要考虑常见的各种注入,越权操作即可. 互联网的安全远远大于后台管理类的安全.简单说来,能不采用ajax就不采用ajax,本质上所有ajax都是接口.
这套框架除了工作上的需要以外,更多的体现了,我的技术观对于技术的要求比较高,而对现状不满意,所以才会自己造轮子.在明确自己方向和目的以后,事情就会变得好办,逢山开路,遇水搭桥. 在造轮子的过程中,兼容性是最大的考虑方向,其次是开发人员的开发接口(编程方式),这边分别体现了我的世界观
这套框架更多的是为产品研发.
产品和项目最大的不同在于,项目是在特定环境上开发的,基本不用考虑迁移.而产品是在外部开发,要融入到目标的技术生态内.只要是产品,就需要考虑如何兼容和集成.
面对相似的功能,能不能抽象组件,抽象什么样的组件,组件怎么被集成使用,这些问题一致困扰着产品研发团队.产品研发团队内部需要处理更高层次的复用.但是更高的抽象层次意味着更高的思维空间,意味着更高层次的实现难度,这种空间和难度在项目开发中,往往会被忽略或者绕行.
根据中国的特殊国情,一般产品的销售会伴随着实施和二次开发.而产品团队和实施团队虽然是一家公司,内部却并不是一个团队.一般产品内部还要求隐藏部分的核心逻辑,而负责交付的团队,在面对复杂多变的业务需求时,希望有更多的灵活性,同时需要了解内部原理,解决更多的问题.正是因为这种软件产品交付模式的存在,同时带来的还有产品研发团队在管理软件版本的时候,增加很多成本.
- 我认为,产品架构师有一个职责是,做一个优雅的骑墙派.骑墙体现了兼容性,优雅体现了开发接口上.
- 一个框架要大量推广的前提,一定是具备非常优秀的开发接口.
产品级框架的主要思考点
技术掌控力,何谓掌控力,就算有人把天捅穿了,要能补好的能力
如何让产品可以兼容不同的部署环境,不同的数据库,不同的web容器,不同的网络拓扑,不同的中间件环境
公司内不同部门的同学如何相互协作??中间件组和业务产品组怎么协作,产品组和现场组怎么协作??
提供的组件怎么升级?
现场的二次开发和产品的版本怎么配合,既能回收功能需求,又能支持持续输出?
怎么样提高开发效率,提高容错能力,降低出错的概率,需要足够的技术输出,才能让所有人都具备能力
初心
如果最终的技术提供方可以承诺一个事情,"所有封装的内容,不允许修改,且一键升级,所有不封装的内容,随意修改",那么上述的很多问题都会比较快速的解决.
但是技术方要做到这种程度,需要对产品结构做比较大的调整,可以最终归结为一个问题,"功能模块的拔插",拔什么,插到哪?
基于这个问题,一个完整的产品级框架就是不可或缺的存在,只有在底层明确以后,逐渐往上层推广,才能最终做到所有封装的内容,不允许修改,且一键升级,所有不封装的内容,随意修改
天发杀机，移星易宿；地发杀机，龙蛇起陆(启路)；人发杀机，天地反覆.-----<道德经>