目前社区越来越靠近开源，很多的基础架构也不在从头造轮子，都是基于开源项目的基础上进行再一步封装。比如针对restful，通常是使用开源的jersey。但是开源的产品通常都是提供核心功能，并不能提供企业级运行所需要的功能。这就需要我们哪来一个开源产品进行进一步封装。

很多人经常提问，封装到底到底需要考虑哪些方面呢。 由于是博客，不能介绍细节，我只是说说大概的思路。

对于一个service 服务的注册和路由，协议转换，序列化、反序列化等等，这些都是有开源框架完成的。我们就不赘述了。

大概的设计方向是

需要实现pipeline 引擎来进行业务扩展。 这个引擎或者利用filter 或者自己实现都是可以的。 pipeline 定义request 和response pipeline 的 单元及顺序。 让在进入用户的逻辑之前有能进行逻辑的扩展。

• Request pipeline  
• Response pipeline   

从下面几个方面收集数据

Transaction

   Logic

• Traction type 
• Transaction time
• Failure
• Warning
• long time transaction 
• Total Count 
• Raw log

   Box 

• tps
• GC overhead
• CPU usage
• memory available
• threads 

Event

• count
• Raw log

需要在合适的生命周期进行配置的初始化。如读pipeline的yaml配置pipeline， 初始化有不同的策略

• 容器启动时
• Service 被调用时
• 容器启动好，应用程序warm up 阶段。

通常大家都会选择容器启动时。

• Authn/Authz  在request 进入用户逻辑前进行权限校验，是不是valid 用户，能不能调用这个call
• handshake 来校验token
• Ratelimiter  限流判断，防止用户进行DOS攻击。
• https support， 目前流行的是tls1.2 ，这个需要用户可以配置。
• 服务应用的token 来表示这个应用是被允许上线的。

• server timeout 来保证long connection 不会用光线程池，考虑readTimeout 和 connection timeout
• client 端 要用hystrix 的断路器来保证连接
• 根据异常的数量和趋势自动进行markdown 停止服务
• 根据流量自动进行markup 或者提供手工markup 的能力 

• 服务的注册，包括service name, url, protocol, service discovery label,  configuration，port
• 服务的动态修改, 可以在线调整服务的各种参数， 比如timeout

服务的发现，结合服务注册中心， 或者k8s istio，或者pure envoy实现，根据架构的不同提供不同的注册功能。

• 服务的动态修改, 可以在线调整服务的各种参数， 比如timeout

我们通常会提供服务的一个id，来标识这个服务。

服务通常是一个调用链， 这是一个分布式的分散的调用链。 对于一个request 的call ，整个链路都需要能够看到能够trace。 opentracing 是一个很好的标准，可以选择不同的实现。

log 通常需要记录本地的exception ，同时这些分散在不同box 的log 最好能够发送到后台的log 服务， 类似于 CAT， 能够聚合来方便观察监控。

如果service 部署到不同的国家， 异常的信息，或者返回的信息就需要考虑国际化。

Service 需要一个UI 来进行admin 的管理工作。

1. 实时状态显示

2. 参数的动态修改

3.  线上问题的紧急处理。

这部分是最容易比程序员遗忘的。写了代码，通常不在乎实施的人怎么处理问题。 但是在紧急的问题处理中， 很多service 是不能出错的。或者出错的时间不能很长，那么针对不同的情况，  作为开发者比较要提供一份详细的SOP来作为预案处理。