微服务怎样才能真正“微“起来
微服务这些年比较时髦，用 Java 取代 SQL 及存储过程开发业务逻辑，确实能获得架构上的优势，细节这里就不展开了，微服务能流行当然有它的道理。
但微服务真地“微”吗？
我们知道，面对同样业务逻辑时，Java 写出来的代码远比 SQL 要长，10-20 倍的样子。即便有了 Stream,Kotlin 以及 Scala 这些新类库和新语言的协助，面对稍复杂些的运算需求，代码量还是远远超过 SQL 及存储过程相比，从这个角度上看，微服务一点也不“微”
服务端是这样，应用端更是这样。原本直连数据库写句 SQL 就能做的事，现在改从微服务获取数据后，再想搞个分组连接都麻烦得要死，还是几百行。所以基于微服务做报表一直是个难题。
即便在微服务强调的架构方面，微服务也不够“微”。微服务是为了让业务之间解耦，这样能更从容地应对频繁的变化。但 Java 是个编译语言，代码改动时要重新编译部署，过程繁琐不说，还有可能迫使整个应用中不相干的部分也一起联合编译部署。想把各个服务独立起来，还要使用 Docker 甚至虚拟机这种沉重的机制，无法做到轻量级热切换，这对于本来想适应频繁变动业务的微服务十分不友好。
借助 esProc SPL 就可以让微服务真正“微”起来。
esProc SPL 是 Java 写的开源软件，在这里https://github.com/SPLWare/esProc 找。
我们来看 esProc SPL 如何解决微服务不够“微”的问题。
Java 为什么开发会比 SQL 繁琐的原因，说起来一时话长，以后再专门讲一期。
SPL 克服了 Java 的问题，提供了比 SQL 还完善的结构化数据对象和更丰富的计算函数，在这些基础上，SPL 代码通常会比 SQL 更简洁易维护，比 Java 写出来的当然就更简单 多了。
通常的分组、关联等集合运算都能支持得很好，它是完全自己做的，并不会翻译成 SQL。
Orders.sort( -Client, Amount)
Orders.groups( year(OrderDate), sellerid; sum(Amount), count(1) )
更复杂一些的任务，比如这个，计算有哪些股票连涨过 3 天以上，SQL 代码冗长且难懂：
WITH A AS
(SELECT code,date, price-LAG(price) OVER (PARITITION BY code ORDER BY date) RisingPrice FROM stock)
B AS
(SELECT code,
CASE WHEN RisingPrice>0 AND
LAG(RisingPrice) OVER (PARTITION BY code ORDER BY date) >0 AND
LAG(RisingPrice,2) OVER PARTITION BY code ORDER BY date) >0
THEN 1 ELSE 0 END Rising3DaysTag FROM A)
SELECT DISTINCT code FROM B WHERE Rising3DaysTag =1
同样的计算逻辑，用 Java 会更为繁琐，但用 SPL 就非常简单：
A |
|
1 |
=stock.sort(date).group(code) |
2 |
=A1.select((a=0,~.pselect(a=if(price>price[-1],a+1,0):3))>0).(code) |
SPL 还有完善的流程控制语句，像 for 循环，if 分支，以及子程序调用。这相当于结合了 Java 过程处理能力和 SQL 的数据处理能力，所以代码会比这两都更简洁。
SPL 代码写在格子里，这和通常写成文本的代码很不一样。这样可以更方便地编写调试代码。SPL 也提供完善的调试功能，如单步执行、设置断点、所见即所得的结果预览，提高开发解析。
SPL 也支持丰富的数据源，无论关系数据库还是 NoSQL 或者 Hadoop/Kafka 都可以连接读取。特别是微服务常用的 Restful 接口以及多层 json 格式数据，都能支持得很好，可以方便地访问、解析并生成。以提高微服务的开发效率，从而让微服务在开发和代码都“微”起来。
我们再看架构方面。esProc SPL 是纯 Java 软件，能够以 jar 包的形式无缝嵌入到任何 Java 应用中，就和程序员自己写的代码一样，一起享受到成熟 Java 框架的优势。esProc SPL 提供了标准 JDBC 接口，Java 程序可以像执行数据库 SQL 或存储过程一样调用 SPL 代码。这相当于把一个轻量强大的数据库引擎引入到 Java 中了。
SPL 是解释执行的，代码修改后不需要再编译部署就能立即生成，这就天然做到业务逻辑的热切换，特别适应微服务针对的业务多变的目标场景。
SPL 脚本可以存储成文件，置于主应用程序之外，每个服务对应一个 SPL 脚本，天然具有独立性。不再需要使用 Docker 或虚拟机这些额外机制，消耗的资源很少，架构也变得更“微”。
在 esProc SPL 的加持下，微服务才真正能成为“微”的服务，也更适应于“热”的应用。
英文版