标签：restful pipeline 停止 trace type 基础上 线程池 handle box
目前社区越来越靠近开源，很多的基础架构也不在从头造轮子，都是基于开源项目的基础上进行再一步封装。比如针对restful，通常是使用开源的jersey。但是开源的产品通常都是提供核心功能，并不能提供企业级运行所需要的功能。这就需要我们哪来一个开源产品进行进一步封装。
很多人经常提问，封装到底到底需要考虑哪些方面呢。 由于是博客，不能介绍细节，我只是说说大概的思路。
对于一个service 服务的注册和路由，协议转换，序列化、反序列化等等，这些都是有开源框架完成的。我们就不赘述了。
大概的设计方向是
需要实现pipeline 引擎来进行业务扩展。 这个引擎或者利用filter 或者自己实现都是可以的。 pipeline 定义request 和response pipeline 的 单元及顺序。 让在进入用户的逻辑之前有能进行逻辑的扩展。
从下面几个方面收集数据
Transaction
Logic
Box
Event
需要在合适的生命周期进行配置的初始化。初始化有不同的策略
通常大家都会选择容器启动时。
服务的发现，结合服务注册中心， 或者k8s istio，或者pure envoy实现，根据架构的不同提供不同的注册功能。
我们通常会提供服务的一个id，来标识这个服务。
服务通常是一个调用链， 这是一个分布式的分散的调用链。 对于一个request 的call ，整个链路都需要能够看到能够trace。 opentracing 是一个很好的标准，可以选择不同的实现。
log 通常需要记录本地的exception ，同时这些分散在不同box 的log 最好能够发送到后台的log 服务， 类似于 CAT， 能够聚合来方便观察监控。
如果service 部署到不同的国家， 异常的信息，或者返回的信息就需要考虑国际化。
Service 需要一个UI 来进行admin 的管理工作。
1. 实时状态显示
2. 参数的动态修改
3. 线上问题的紧急处理。
这部分是最容易比程序员遗忘的。写了代码，通常不在乎实施的人怎么处理问题。 但是在紧急的问题处理中， 很多service 是不能出错的。或者出错的时间不能很长，那么针对不同的情况， 作为开发者比较要提供一份详细的SOP来作为预案处理。
标签：restful pipeline 停止 trace type 基础上 线程池 handle box
原文地址：https://www.cnblogs.com/developernotes/p/14683679.html
