如果要在计算器的业务逻辑加上其他操作符运算，能否不影响原来的业务逻辑？这时可以用继承、多态的面向对象思想方法把各种操作符分开不同的类，如果要改动或增加删除某一个操作符，都不会影响其他操作符，这就进一步降低了耦合度。
先说紧耦合，这种架构是我们在Laxcus 0.x、1.x中采用的。紧耦合架构本质是一个Client/Server模型。客户机发起请求给服务器，服务器收到，根据请求做出应答，然后反馈给客户机。这种架构最典型的应用就是我们每天都用到的WEB服务。优点嘛，就是简单。架构简单、设计简单、开发周期短、能够快速投入部署和应用。在Laxcus集群的早期运行中，这些特点都得到有力的验证。
但是到了后期，随着Laxcus集群规模的不断扩大，访问量的不断增加，尤其是数据计算量、计算时间成倍数的增长后，紧耦合架构渐渐不堪重负，缺点开始不断暴露出来，主要有以下几个方面：无法支持大规模的计算业务；计算机载荷无法控制；任务执行过程中管理难度大；对网络资源消耗大；安全控制力度差；程序代码之间关联度过高，不利于模块化处理；以上现象最终导致系统稳定性变差。
这些问题出现后，我们开始考虑修改系统设计。经过多番考量、比较、权衡之后，我们决定改用松耦合架构重新规划系统设计。新框架是在原来Client/Server模型之上的改进，即在Client/Server模型之间加入一个代理（Agent），把CS模型变成CAS模型。在新的架构下，客户机的角色不变，代理服务器承担起与客户机通信，和对客户机的识别判断工作，服务器位于代理服务器后面，对客户机来说不可见，它只负责数据处理工作。另外我们也把CS模型的同步操作改为CAS的代理处理。 　　 在设计新架构的同时，我们还发现，如果要适应松耦合架构，原来在紧耦合架构下运行的程序代码，因为现在的工作方式发生了发生了变化，它们几乎都要重写。这可是一个庞大的工程，需要消耗大量的人力、时间去修改和调试。所以我们在松耦合架构之上，结合代理服务器，又设计了一套Invoke/Produce机制。这是另一种代理方案，是针对数据处理进行抽象化处理和分组分级管理。原来的数据处理和业务逻辑套用这套机制后，程序代码基本不用修改，转移到CAS模型上运行就可以了。

KitDB 是一个内嵌式持久型的高速 NoSQL 存储 lib，以 jar 包方式嵌入到应用中。

KitDB 提供了类似 Redis 的数据结构。如 KV、List、Map、ZSET 等。也提供了 TTL（生存时间）、备份、ACID 事物，多节点强一致性等功能。

KitDB 完全基于磁盘存储，并提供最高百万级别的查询性能和十万的写入性能。

KitDB完全基于磁盘，不受内存限制；KV、List、Map、Zet、ZSET 等丰富的数据结构；最高百万级别的查询性能和十万级的写入性能；原子性写入，读写无冲突；拥有TTL（生存时间）；支持备份与恢复；ACID事务多节点一致性支持（官方插件使用 Raft 协议支持强一致性，也可自行使用其他协议或方式）。

项目地址： http://kitdb.top/#/

删除本地缓存，然后在编辑 .gitignore 就可以生效了

// package-lock.json 是你要删除的文件
git rm --cached  package-lock.json

javascript一直是个谜，近两年出了新玩法，不光能写网页，还能写后端，写桌面端，这个对于前端开发人员来说，简直是一个福音！

之前在开发桌面程序的时候，对比了一下nw.js 和 electron, 最后选用electron来开发，electron整体效果还不错，体验上和原生的区别不大，唯一的缺点就是打包出来得应用太大了，初始打包就高达49M，这个对于一些小工具来说，简直就是一场灾难

经过一番搜寻，找到了两个指数较高的打包工具，一个国产的，另外一个是国外的

https://miniblink.net/

https://opencollective.com/tauri

从功能上来看，tauri的生态更为丰富，有较多的维护者，欢迎入坑！