Redkale 讓你重新認識Java
Java 已經22歲了，依靠強大的功能、龐大的開發社區和無人能及的生態系統，長期占據世界編程語言排行榜首，成為當之無愧的業界之王。本人在大學時期被這種很有藝術性的開發語言所吸引，果斷拋棄C，學習方式很簡單，只看JDK API源碼，直到現在都是如此。剛畢業就一直從事Java開發方面的工作，至今也有十來年了。從JSP、WebWork到Struts、JSF，從JDBC、Hibernate到TopLink、JPA。從NIO、Mina到Netty、Grizzly。很多框架都用過，研究過。后來漸漸覺得各階段主流的框架功能很強大，設計理念也很好，但是我們大部分情況只使用其中一小部分功能，框架在實現上性能也普遍一般(除少數追求性能的框架)，且適應新版JDK發布版本普及也會滯后兩三年以上。慢慢地發現用了那么多整合的框架并沒有比JBuilder時代的開發速度敏捷多少，很多時候在原始的Servlet、JDBC基礎上做一定的封裝就能滿足大部分的需求。人人覺得一個優秀的框架除了保證性能和穩定性，也要注重簡易性，而不是滿足開發者需求的同時大量依賴包、繁瑣的配置(過多的配置性的注解也是配置)和臃腫的jar刷其存在感。在長期看JDK API源碼、學習開源框架設計理念和參考JavaEE規范接口設計的習慣下自然有了自己的思路和設計想法，開始學寫自己的框架。于是，在2015年框架基本雛形出來并命名為 Redkale ，2016年正式開源。
太臃腫
如今在Java界，Tomcat、Struts2、Hibernate、MyBatis、Jetty、Spring MVC/Spring Boot/Spring XXX這些框架大家都耳熟能詳，似乎不懂其中一二都不好意思說自己會Java，Spring已經成了Java的代名詞，很多四五年以上的開發人員只識開源框架不識JDK，談起這些框架的原理、優缺點，各種SOA、集群、分布式、事務、微服務概念頭頭是道，都可以出書了，但是寫出來的代碼或做出來的數據結構設計，堪比實習生。2004年發布正式版的Spring以其輕量著稱，一戰成名，打敗了J2EE，成為Java事實上的"標準"。然而經過十幾年的發展，其生態越來越龐大，功能的增多，復雜的配置，兼容性，歷史包袱，使得整個框架體系越來越臃腫，還有不計其數的衍生插件，已經不比當年J2EE輕多少了。在那個JBuilder還是主流IDE的年代，建一個Web系統還是比較簡單，除了Tomcat比較大點，其他都算輕量。現在很多人建一個Web項目，需要復雜的Maven建工程，一行代碼還沒開始寫，僅僅是導入SSH/SSM這些框架就需要好幾十M，還得進行一堆SSH配置,簡單的日志都需要配備log4j/snf4j。可能只是簡單的管理系統，必須要搞這么復雜嗎？ 現在一個1-2M的框架大家都認為是輕量級，MyBatis是JDBC基礎上的再次封裝，jar包大小近6M，但比Hibernate還是輕量些。這些只是基礎框架，如果系統還需要其他功能性的框架(Lucene、Mail、Json) 會使開發包更大。同時大量的開源框架抑制了新JDK的普及，NIO出來都十五年， AIO(NIO.2)也出來六年了，如今還有很多人把NIO給貼上高性能的標簽，JDK 5——Java第一個重大更新的版本在2004年發布，直到五-六年后Spring的注解方式才得到普及(Spring舊版本xml方式普及度高)， Java第二個重大更新的版本JDK 8發布也有三年了，大部分人還停留在只識語法糖Lambda的程度，在JDK功能越來越強大的情況下，開發Java系統并不簡化多少。相對于現在流行的NodeJs做個Web系統來說，Java就是個巨無霸。其實呢，Java無需這么復雜，真的可以很簡單。
異步呢
用Java開發異步系統是件很難的事情，首先Java規范中異步接口很少，Servlet 3.0雖然支持異步，也出來好幾年了，但現在直接用Servlet寫代碼的人已經不多，而基于Servlet的Struts、Spring Boot這些框架又沒把異步太當回事，基本都是實現的Servet同步方法。其次JDBC更是迄今為止還沒有異步接口，基于JDBC的Hibernate、MyBatis同樣不會有異步接口。再者開源框架以異步接口為主的鳳毛麟角。 所以Java程序員在寫業務代碼時基本都是用同步方式，特別是最耗時的數據源操作JDBC無法異步。
@WebServlet(value = {"/order/*"}, comment = "訂單模塊")
public class OrderServlet extends HttpBaseServlet {
@Resource
private OrderService service;
@WebMapping(url = "/order/find", comment = "查詢單個訂單")
@WebParam(name = "#", type = long.class, comment = "訂單ID")
public void logout(HttpRequest req, HttpResponse resp) throws IOException {
long orderid = req.getRequstURILastPath(0L);
resp.finishJson(service.findOrder(orderid));
}
}
@Comment("訂單服務")
public class OrderService implements Service {
@Resource
private DataSource source;
@Comment("查詢單個訂單")
public Order findOrder(long orderid) {
return source.find(Order.class, orderid);
}
}
以上范例是大多數Java開發者的常規寫法，Servlet調用Service，Serivce調用數據庫操作返回結果，都是同步操作, 而基于JDBC的開發使得最耗時的數據庫操作占用了大量的線程時間，即使HTTP使用NIO、AIO(NIO.2)都收效甚微。而在NodeJs里，IO操作都是異步的。如下：
http.post("/url", {id:10}, function(request, response) {
service.getResource(request, function(result){
response.write(JSON.stringify(result));
response.end();
});
});
var mysql = require('mysql');
var pool = mysql.createPool(config);
pool.getConnection(function(err, connection) {
connection.query( 'SELECT * FROM table', function(err, rows) {
connection.end();
});
});
這也是Nodejs做些小系統比Java還快。Java在語言和IO上的性能優勢彌補不了同步來帶的線程消耗。
Redkale 一個全新設計的Java異步微服務框架。集HTTP、WebSocket、REST、JSON、RPC、DB操作、依賴注入等功能于一身，其 redkale-1.6.1.jar 包大小僅790K，且不依賴任何第三方包。大部分框架自身就很龐大，滿足了開發者的需求同時也帶來復雜的配置。如同上班只有三四里路，要買輛汽車代步，開車輕松的同時會帶來車的保險保養，堵車，加油，下車庫，找停車位等副作用， 其效果還不如一輛自行車來得簡單高效。 Redkale 返璞歸真，拋棄沉重的歷史包袱(javax.servlet、JPA等)，基于JDK 8設計微服務架構，盡可能挖掘新JDK的優勢，在保證高性能的情況下追求框架的簡易性。其核心分三層結構：接入層Servlet、邏輯層Service、數據層Source。 并且三層都支持異步接口，從HTTP接收請求到Service處理邏輯再到Source拉取數據，全程都可異步，最大限度的提高CPU使用率。為適應前后臺分工的開發場景， Redkale 提供方便的API文檔生成功能，無需編寫標準的Doc文檔也能讓前端開發人員知道后臺API接口。
Servlet
在API設計上， Redkale 下足了功夫，敢于拋棄標準。其HTTP服務不再是javax.servlet——J2EE中使用最多的規范的實現，在接口形式上與NodeJs的HTTP模塊很類似，易于操作。Servlet規范對于現在的應用來說過于體系化。時下移動APP、發達的前端、高性能瀏覽器、靜動分離、REST、分布式這些因素已經讓JSP、PHP、ASP這些通過后臺生成頁面的集中式開發框架顯得不適時宜。NodeJs中的HTTP模塊源碼不過十幾K，而Java里HTTP服務主流還是Tomcat——一個8M的重型機器。 Redkale 摒棄了已經落伍的規范和功能(JSP、InputStream/OutputStream操作、Session對象、Filter等)，弱化Web概念，HTTP與SNCP服務一樣，只是接入層，無需做過重的設計。
其他語言的HTTP框架在處理請求后大多是以response關閉整個請求處理的方式為主，而Servlet規范卻是在service方法執行后關閉，Servlet3.0規范雖然支持異步，顯然與其他語言框架比，比較生澀難懂，其API使用方式還需與同步方式區別對待，且接口設計本身就會導致實現上性能不佳，而response關閉的方式天然的把同步與異步等同對待，無論是當前線程還是另開線程處理請求，都由response來結束請求處理。同樣Servlet規范中WebSocket接口設計上也是過于復雜，且只是針對協議本身的實現，沒有考慮大多開發者的使用場景，WebSocket本質上就像一個keepalive的Http請求,雷同HttpServlet。所以 Redkale 在設計WebSocket時盡量與HttpServlet形態保持一致，同時還集成了分布式功能，讓開發者也可以很簡單的實現多部署。
Service
Redkale 所有API設計中最精簡的當屬RPC功能，RPC沒有直接調用的API，其功能依附在Service。RPC或類似功能的框架在Java里一直是比較重量級的，從古老的Corba、RMI到后來的EJB、WebService，還有其他很多RPC開源框架，都有著復雜的配置和大量API學習成本，有些還需要區分客戶端和服務端(如WebService)。 Service不僅只是個邏輯層的規范定義，還集成了很強大的RPC和異步調用功能，遠程模式的Service就是RPC功能，系統在依賴注入過程中創建Service時通過基本的IP配置自動識別是創建本地模式的Service還是遠程模式的Service，遠程模式的Service使用的就是RPC，但在代碼層Service的調用本地模式與遠程模式完全一樣。更神奇的是，帶有異步回調函數AsyncHandler 的Service方法同樣能執行遠程模式。這種RPC的簡易性是其他框架都無可匹敵的。REST風格的Service在接口設計上盡量減少注解性的配置，同時保留靈活性,減少HttpServlet的編寫。
Source
除了開發類似數據庫管理工具，大部分情況下開發者只用基本的增刪改查操作，Hibernate、MyBatis這些框架對于對象新增/更新/刪除和主鍵查找對象等接口定義都比較簡單，但是帶有過濾條件的操作，就變得難用。MyBatis需要配各種SQL，大量if else，Hibernate需要寫HQL或SQL，JPA規范需要寫JPQL或使用Criteria功能。過濾查詢、翻頁查詢、過濾修改、局部修改、過濾刪除都是很常見的操作，而主流ORM框架對這類操作進行簡化程度很有限。 Redkale 結合常規的使用場景，以JavaBean的方式提供過濾功能，無需編寫SQL或類似SQL的配置，使過濾性的操作(刪改查)API變得異常簡單。DataSource另一個亮點是分表分庫操作與單表操作的API一樣。同時每個操作都提供成異步接口，但是又限于JDBC的同步性，DataSource的默認實現提供的異步接口也只是JDBC的同步操作，若開發者追求性能極致的話，可以使用AIO(NIO.2)技術編寫不基于JDBC的DataSource異步實現。 DataSource提供的緩存功能還能保持進程間的同步(得利于RPC)。
思維
Redkale 追求大道至簡，不僅提供高性能的功能和簡易的API，還帶來不同的設計思維。作為一名有追求的開發者，不能只停留在API層面，更多的是需要掌握設計能力，一個好的設計方案往往能少寫很多代碼。Java里很多規范和框架就是考慮太過全面，為了迎合各種良莠不齊的想法和設計。比如HTTP服務，只是系統的一個接入層，有必須設計ServletConfig、ServletContextListener、Filter、HttpSessionListener等這么多API嗎，開發者在系統初期養成定義全局的BaseHttpServlet這些基類的習慣就可以控制很多東西，也無需去使用什么攔截器或AOP功能。提交表單前先將表單數據轉換成JSON字符串傳給后臺，后臺的接口既可用于Web也可用于APP，非要按原始表單提交，那只能使用Struts這類笨重的框架了。再如DB操作，開發者設計好的數據結構可以把關系型數據庫當NoSQL數據庫操作，會發現對JDBC做一定的封裝就可以基本杜絕寫SQL。非要寫存儲過程、關聯五六張表進行復雜查詢，再好的DB框架都滿足不了你。再如Date，Date對象的本質是long值，很多人習慣性的數據庫就用Date類型，這樣會增加很多麻煩，增加數據庫的通用性難度，JSON還需要提供各種DateFormat，如果使用long類型，時間只交給頁面去format就簡單很多，long的性能也更好。說了這么多，只是想表達一個觀點，開發時擺脫傳統思維的桎栲，換個思路去思考，很多東西會變得很簡單。
想了解更多關于Redkale的資料， 請訪問Redkale官網: ： http://redkale.org 。
來自：http://www.iteye.com/news/32264