我正在努力将应用程序从Spray.io迁移到Akka-http。该应用程序是基于微服务的,具有许多我们构建的小型库。以下是在一个特定微服务中编写指令和路由的示例:
SELECT DISTINCT TABLE_B.*
FROM
TABLE_A
JOIN
TABLE_B
ON
TABLE_A.COMMON_ID=TABLE_B.COMMON_ID
AND TABLE_A.SEQ_3C=TABLE_B.SEQ_3C
JOIN
TABLE_C
ON
TABLE_A.COMMON_ID=TABLE_C.EMPLID
WHERE
TABLE_B.ITEM_STATUS<>'C'
and TABLE_A.CHECKLIST_STATUS='I'
and TABLE_A.ADMIN_FUNCTION='ADMA'
and TABLE_A.CHECKLIST_CD='APPL'
and TABLE_A.COMMON_ID = '123456789'
and TABLE_C.ADMIT_TERM='2171'
and TABLE_C.INSTITUTION='SOMEWHERE'
除了val routes =
(decompressRequest & compressResponseIfRequested) {
metricsRoute ~
healthStatusRoute ~
apiRoutes // only these are my app's routes
}
之外,所有上述内容都在内部库中定义。
我想在这个微服务中开始使用Akka-http(将apiRoutes
迁移到Akka-http)而不更改我当前使用的任何库,因为这会强制所有其他开发人员改变他们的代码在同一时间。
这可能吗?有没有办法让Akka-http使用Spray.io指令/路由?
据我所知,migration guide没有这样的信息。
答案 0 :(得分:3)
这并不困难。如您所知,Spray中的Route
为RequestContext ⇒ Unit
,而Akka中的Route
为RequestContext ⇒ Future[RouteResult]
(当然,其RequestContext
版本均为~
。我所做的是创建一个包装器,它可以包装一个Spray路由,通过Spray服务actor提供这种转换。路线被单独包裹,然后根据需要折叠RequestContext
以完成顶级Akka路线。随着时间的推移转换是一个逐个删除包装器直到所有路径都已转换的过程。
由于您要将转换为 Akka,请从Akka HTTP套接字处理程序和折叠结果开始。现在,您将为此折叠添加包装的Spray路径。
就其本身而言,未转换的Spray指令想要响应一个Actor,因此你的包装器会为被包装的路由创建一个服务actor。将此actor呈现给Akka很简单:使用Future[RouteResult]
并返回ask()
的函数与服务actor上的RouteResult
相同,并返回一个Future
的消息1}}(由ActorSystem
方便地包裹在HttpServiceActor
中。除了Actor之外,这个包装器大约有十行代码。
服务主角本身扩展Spray RequestContext
并接受一条消息,即Akka RequestContext
。此消息被机械转换为Spray self ! ctx
,处理所需的任何使用模式。该消息处理程序的最后一行是HttpServiceActor
,将已翻译的上下文发送到超类中的Spray withRouteResponseMapped()
处理程序。
结果转回Akka是通过RequestContext
发送给Spray的RouteResult
。您传递的函数反过来,将Spray构造映射回Akka并返回HttpEntity.Strict
。如果您只是执行<ul data-ui="accordian">
<li data-ui="expandable">
<a href="#" class="Toggle">Main accordion title here</a>
<div class="content">
<ul data-ui="accordian">
<li data-ui="expandable">
<a href="#" class="toggle">Inner accordion title to expand</a>
<div class="content">
<p>some text here</p>
</div>
</li>
...
...
</ul>
</div>
</li>
</ul>
返回值,这非常简单。
我希望我可以在这里发布代码,但它是为客户编写的,他们对IP共享有未知(但显然是严格的)限制。