一次技术问答

最近一年多都没有写博客了,技术上做了很多有意义的事情,也有一些经验上的积累,逐步沉淀到博客上。

今天回答某公司的技术上的一些疑问,把问题和回答贴上来。逐步

1

自己的技术观。

1. 如何做数据安全防范?还有哪些支付安全需要注意?

数据安全防范主要分为两个方面:

  1. 内部

    • 数据库管理员职责单一,不能既懂业务,又懂数据库
    • 数据库合理管控
    • 日志脱敏
    • 线上导入到线下的测试数据需要审核
  2. 外部

    防止数据被泄露出去,比如sql防注入,服务器权限合理管控,数据访问需要进行合理的授权(比如遍历id就能把数据查出来)

技术上的安全关注下owasp top 10,业务上的安全需要属于风控了,这块我了解的比较少,比如基本的同卡进出。

2. 认证授权怎样拦截无效用户?

上下文说得不是很清楚。我理解为,认证服务的能力。除了功能性需求,可能还需要一些非功能性需求。比如认证服务需要使用缓存,认证服务需要有限流。

3. 分布式性能提升的方案. 数据模型设计有哪些最佳实践?

这个话题太大,我只能大概说下:

  1. 首先要平衡组件和服务之间的关系,毕竟分布式第一定律:不要分布式
  2. 分布式场景,应该要考虑允许数据不一致的情况,合适的引入缓存
  3. 所有的性能问题,其实是怎么把资源榨干,了解各种资源的特性,就了解了如何取舍资源利用率
  4. 性能需要考虑,在项目前期,要对性能有预期,留下足够扩展的点,不要过多投入,也不能完全不管。

4. 交易相关分布式事务控制. log的处理方式. 异常处理机制请随意分享一些实际的经验

  1. 分布式事务不要碰,简单的做法:服务提供方幂等+服务使用方努力尝试。这样做开销最小,毕竟失败不是常态。
  2. log不要阻塞业务的执行。log中应该要保留请求唯一id,便于做链路分析。open-tracing还不错。
  3. 异常的处理原则:a. 业务尽量不要处理异常,交给框架,这样代码写起来会很优雅(框架异常处理器来处理)。b. 不要吞掉底层异常 c. 业务异常要考虑下是否必须收集栈信息(不收集栈信息可以减少日志,并提高性能)

5. 分享一下中间件使用场景

1
中间件
这个词太大了。没办法讲。

6. 用dubbo框架多服务之间rpc调用同步返回这种需求有什么好的方法来保证实时性返回,因为整个服务链调执行完后还需要每个链路挨个返回效率很低

这个不是dubbo的问题。该异步的异步,该并行的并行,能缓存的缓存,性能自然好了。

7. 封装mq做同步返回替代rpc同步返回机制是否可行

mq做同步返回?mq本来就是异步的,同步只是在交互上的同步,由两个异步的场景+等待组合成对外部的异步,这样做意义不大把?

soa中,dubbo只是提供了一种解决rpc的手段,不要忘记,消息在很多场景下比用rpc好得多。

8. 定时服务只能单点部署,如何做高可用

定时任务可以做高可用,开源有解决方案,quartz也有解决方案。两种思路:

  1. 基于quartz官方的数据库方案。
  2. 数据库存任务,用zookeeper之类的来做任务分配,用quartz来做节点上的定时任务。

9. 怎样才能评估服务拆分的合理性

  • 若非可重用,先尽量不要拆分。微服务这样的入大流的名词,做起来需要很多基础设施做支撑。单体应用能支撑得很好,组件化,模块化也很不错。
  • 服务拆分尽量按照领域来设计,高内聚、低耦合是目标(参考面向对象设计的基本原则)。服务粒度靠业务场景养出来的,准则很多,需要根据业务场景来逐步演进。
  • 公司的技术架构能改变公司的业务发展现状!!!技术真的能带来生产力!!!可以参考阿里巴巴
    1
    大中台,小前台
    
    的思路。不过要看阶段,合适的阶段做合适的事情,技术能带来价值,也能带来麻烦。一切都是取舍。

10. web项目分布式集群时session共享有什么好的实践。

spring session+redis或者spring session+内存网格(Hazelcast\ Ignite)

11. Dubbo服务不停机升级,如何让正在运行的处理完毕,并且不接收新请求的

我们内部的版本修复了这个问题。步骤如下:

  • provider通知consumer,不要发新请求过来(zookeeper unregister service)
  • provider等待服务执行完毕 (provider计数)
  • consumer等待服务执行完毕 (执行完毕后provider计数)
  • provider关闭
  • cusumer关闭

12. 易极付这边的页面自动生成技术是如何实现的?

通过自动生成的业务主要用于后台管理,包括:新增,修改,删除,分页,导入,导出等功能。做起来比较简单,访问数据库获取元数据,通过freemarker生成代码。

13. 支付系统的异步通知的实现,如何优雅的控制通知的频率

我们内部有一个通知服务,所有要对外通知的系统向通知服务发送消息。通知系统记录任务,通过异步http向外发送消息。每个任务维护通知的状态。现在通知间隔是逐步递增的。

14. 包的版本使用SNAPSHOT,怎样确保使用gradle下载的是最新的jar包

gradle有5年多没有用了,大概参考官方文档gradle:controlling_caching可以做到。

15. 遇到回调先于同步返回的情况,该如何处理?

对于服务调用方,需要考虑幂等。谁先回来都无所谓。

服务发现

服务发现用于动态感知服务提供方地址,并提供服务路由分发策略能力。

1. 客户端发现

客户端从注册中心获取服务列表,客户端监听服务列表的变化,客户端通过路由策略选择合适的服务端地址。

服务端在停服务时,需要先通知客户端不要发送新请求过来,等服务端把当前请求处理完后,才断开连接。

2. 代理端发现

代理端对外提供服务,主要用于对外请求路由。代理端(比如nginx/haproxy)转发请求到后端服务。后端服务暴露地址到注册中心,代理程序动态获取服务地址。

nginx可以试试nginx-upsync-module

在k8s内部,采用nginx+dns+k8s proxy实现。

关于高可用系统

http://coolshell.cn/articles/17459.html

前段时间写了一段公司的公关文(CUI NIU BI),强迫自己写了

1
5个9

作者讲了几个大实话:

如果你没有一套科学的牛逼的软件工程的管理,没有牛逼先进的自动化的运维工具,没有技术能力很牛逼的工程师团队,怎么可能出现高可用的系统啊。

深层次的东西则是——对工程这门科学的尊重:1.对待技术的态度 2.一个公司的工程文化 3.领导者对工程的尊重

佛渡有缘人,点到即止,不强求。

  1. 以前对高可用的关注点主要在应用层面,现在加入运维团队后,高可用的关注点延伸到机房、硬件。
  2. 同城双活只要网络质量靠谱点,还是比较好做,主要是南北请求路由控制和东西流量故障切换。
  3. 把服务不可用的因素分成planned、unplanned,分别设计预案

也许把

1
SLA
写到合同里,我就不敢乱吹牛逼了。

Service Wiring with Spring Cloud

https://www.infoq.com/articles/spring-cloud-service-wiring

这篇文章聊到了spring cloud如何提供配置管理、服务发现、服务路由能力。结合我们的现状谈谈:

  1. 有些应用没有做到cloud-ready,依赖服务地址配置信息写死。。
  2. 内部请求用dubbo,实现了服务发现,服务路由,大多数问题已经hold住了
  3. 自研的配置管理系统可以做到配置动态更新,比spring cloud 下的
    1
    Enabling Dynamic Refresh
    
    做法优雅多不少
  4. 还需要提供http服务的服务注册、发现能力。为外部http负载均衡、内部http服务依赖提供服务发现、服务路由能力