十万的License只取决于一个连接

前段时间看到一份代码，小规模、低难度的一个应用，MVC用到极致，业务逻辑却混成一团麻，应该是中了培训班的毒。现在的程序员，大多是没仔细读过《现代操作系统》，没看过编译原理，不知道堆与栈，没怎么用过C、C++，上手就Java、C#，程序一开就内存狂飙，数据库连接随手就建，但这种人算是相当多了，见多了也就习惯了。

前两天看到一篇文章，作者使用的是InterSystems的数据库，这是一个美国公司，为医疗卫生行业提供重要的网络平台，不少国外的IVD厂商都有用到。作者描述的问题很简单：

服务器相当的不稳定，每天都会宕机。
挂了的时候所有的程序都连接不上数据库，大概过10分钟左右又好了！
找来找去说是数据库的License不够了，所以不让新的连接上来，那就纳闷了。虽然Intersystem公司卖的License贼贵，一个就要十万块，但是通过加上ECP，基本上就多出来1000个License Units，咋还会不够用呢？

首先，License 授权是个相当复杂的计算方式，拿 SQL Server 来说，SQL Server不同的版本有不同的功能，不仅价格颇有差异，获得许可的方式也不尽相同，高的有1万9千多刀，总的来说，有两种基本的授权（License）模式。

一、“每处理器”或“每核”模式
“每处理器”（Per Processor）授权模式只计算物理处理器的数量，与物理处理器的内核数量无关。按“每核”（Per Core）计数，同时还需要计算物理处理器（插槽）的数量，单个插槽最低需要购买4核。

这一授权模式可以很好的简化授权的复杂程度，不用统计有多少用户（或者设备）会访问SQL Server，以及是防火墙内部还是来自Internet的外部连接。

二、“Server+CAL”模式
CAL即客户端访问许可（Client Access License），分为设备访问许可（Device CAL）和用户访问许可（User CAL）两类。SQL Server及其组件（例如报表服务）提供服务，客户端则是访问这些服务的设备或用户。

购买CAL时需要考虑有多少客户端需要访问SQL Server并从中获取数据，客户端的计算方式与中间层无关，只与最终有多少客户端能够获取（包括浏览、修改、删除数据等）SQL Server服务器中的数据有关。

标准功能每客户端大概940刀。

回到主题，作者在License Usage 里面看到License Usage by User，同一个IP对应多个连接数但是UserID还是一样的，也就是说你开N个连接或者程序，UserID都是相同的，而且都是同一IP地址，当然，用的License也就是一个，但是，你会发现原来它会计算Connections,也就是连接数。
问题来了：

If the number of processes exceeds this maximum, a transition occurs and Caché begins allocating one license unit per process for that user ID. The system presumes that if more than maxconn connections are associated with a user ID, multiple users are accessing Caché through an intermediary, (for example, a firewall system) so additional license units are required. Therefore, when the (maxconn + 1) process starts, the number of license units allocated to that user ID changes from one to (maxconn + 1). Processes started by the Job command are allocated against the process limit of the user ID invoking the Job command.

原来一个License的进程数或者连接数是有最大限制的，如果超过这个最大限制的话，那就变成了每个连接都使用给一个单独License,难怪服务器会爆掉了。

比如我这边看最大连接数是25。
那就很少了，设备启动时候的用Job函数增加的进程也算在内，如果我们在这台电脑启动多个接口那就占用了多个进程数量了，万一多开几个程序，那完了，就爆了。

为啥有这个规定呢？
可能是为了控制你不用路由器的，如果你用路由的话对公网的IP地址都是一样，Cache就没法判断你到底有多少个终端了。
对于这种问题能怎么办呢，只能想办法优化一下连接数了。

这里要吐槽一下，国内的LIS厂家开发人员的水平跟互联网公司差十万八千里，当然，也可以推到DBA身上，因为99.99%的LIS厂家和大部分的医院都没有DBA。无论是内部开发还是第三方调用，都是一个用户，完全不考虑安全性问题，或者也有考虑安全性的，就是不开放数据访问，也不提供接口，逼第三方去想歪招；不过我已经看到有些LIS厂家已经开始提供WebService接口了，虽然没有遵循ASTM协议或HL7协议，但也是一个进步。
回到最前面说到问题，小应用场景或开发环境下，该做的优化不做，如果遇到这样的问题呢，总不能让客户花十万买License，只有优化连接数了，优化、测试的时间成本呢，客户的时间成本呢，或者客户能等你改好吗？