服务能力输出小结

---

title: 服务能力输出小结
date: 2019-02-02 17:20:35
categories:

• 技术
  tags:
• 感悟

---

近期没什么项目做，就做了一个小改进，因目前各个系统中有不少需要pdf转图片的功能。遂将将之提炼成一个服务。既然是服务，如何提供给使用方使用才比较好呢。这里单就如何提供服务做个小总结。

一、定位、明确应用场景

第一步明确自己所提供服务所要服务的场景，即该服务提供的范围，也就是自身定位。

因为没有定位，就没有该服务所要提供能力的约束。
一方面，自己这个服务所要支持多大体量（qps等）,此处会直接影响后面的设计方案；
另一方面，通过定位划分领域边界，不属于该边界之内的应用方可以直接拒绝，从而避免服务的业务方过多过杂，最终吃力不讨好，还容易引起自己服务不支持的口舌之争。

二、引入的风险

采用自己的新服务产生的优点不必详谈。
重点说问题，引入该服务对原有系统的业务逻辑是否会产生影响？

明确该服务的应用场景，尤其是改动之后对原有逻辑产生的影响至关重要。
一般涉及如下两点：

• 业务方面的影响，如果涉及用户体验方面的，需要同步产品、业务方；
• 服务稳定性的影响，如果使用该服务出现问题，最坏情况会对业务方产生多大影响；

对于正常逻辑，业务、开发都知道，但是异常情况，才是需要关注的重点。
先考虑风险，在设计时，才可以合理规避，且发生极端情况时，有容灾、兜底和人工干预的方案。

三、技术评估

经历上述两轮的调研与思考后，才可以制定方案。
【题设】制定方案的时候，服务的能力是转换（文件转图片），其他应该由使用方实现，这样的话就需要预留扩展点，从而设计的不会太僵硬，满足对扩展开放。

下面重点说说体验。

为什么要说体验，因为经过一年的开发，可以明显感觉到：功能完成只能说是硬性指标，而使用的舒畅程度（用起来简不简单），才会影响对方对该功能的评价。

好的体验自然是接入成本很低，如何达到较低的接入成本呢？

我后来整体上考虑，通过提供maven二方包的形式提供服务，减少使用方提供回调服务的配置过程（因为异步转换服务转换完成会有回调，回调需要让业务方暴露回调接口，业务方使用体验不佳）。

在二方包里会有HSF服务的发布过程，使用方如果需要回调，在引入bean使用的过程中实现回调接口方法即可，无需该感知回调接口如何发布。

同时利用模板方法的设计模式，在client二方包中增加扩展点（before&after），增加使用方的扩展性。

接下来，再说下示警。

任何一个靠谱的服务都离不开示警

示警可以在触发异常时，给开发者发送信息（邮件&电话&短信&钉钉）。

示警信息里需要包含上下文环境，因为示警后，自然会面临排查、处理。一个好的示警信息，可以大大提高问题排查的效率。当然，对应异常的异常日志也是需要打印的。

日志的作用，不只是记录，关键节点没有日志是一件非常头痛的事情。所以，我认为 日志之于系统，相当于黑匣子之于飞机。飞机出问题的时候，黑匣子的作用无与伦比。

最后，说说数据

Last but not least

一个服务，开发者应该可以说出rt时间，时间瓶颈花费在何处。

因为之前在做导购的时候，很纠结于rt的时间。为了避免和别的团队的撕逼现象，用数据说话是最有力的方式。所以记录接口的rt时间、成功率也是比较重要的一个环节。同时，使用数据，对于使用方把控整个服务也具有指导性意义。