重构中的内部准备工作

从SSH单体应用到微服务架构-3

Posted by shamphone on August 6, 2016

随着系统改进工作的进行,一些架构性的问题也越来越突出。在开发中,一个遗留接口是否要迁移到微服务架构上,哪些接口应该放到同一个项目上,项目应该如何组织,日志、监控等基础性的工作应该怎么统一规划,都需要从架构的层面来进行设计。

确定目标

公司每一年都会有一个明确的战略目标,这个目标最终会被分解到每个业务上去实施。 对于支付业务,我们的目标是:

持续提升支付成功率
支付成功率是支付业务的最高衡量指标。提升成功率的首要措施是提升系统的稳定性,在此基础上,通过简化支付流程、优化支付路由等措施,提升转化率。

持续降低支付成本
在保证支付的稳定的前提下,引入更多底成本的渠道,通过支持渠道优惠活动等措施,来降低支付成本。

支持进入新市场
配合公司的市场拓展需求,为新市场提供支付支持。

制定原则

为了和目标保持一致,我们制定了一些微服务的架构规则。当然,这些规则也是随着团队的进步、业务的变更做调整。 我们的原则是参考Heroku的12 Factor而制定的。

以下原则是在刚启动微服务架构改进的时候制定的。

虚机开发
所有开发工作必须在虚机上进行,不得使用个人物理机开发。这使得开发人员能够随时在任何地方调起开发环境,避免由于环境配置问题而影响问题修复。

版本控制
使用Git做版本控制。 每个项目都有一个基准代码库,部署时从主干获取代码。上线时对主干打Tag,每个Tag对应一个线上可执行代码。 测试环境、预部署环境和线上环境都使用相同的基准代码。

代码审核
为了保证代码质量,所有代码必须通过至少两位工程师的审核才可以签入到主干版本中。执行日常代码审核,避免在部署前进行突击式审核。

自动部署
开发人员不得直接将开发机上的构件推送到测试、线上环境。 build, release和run必须分离。 自动部署系统(Jenkins)将从版本控制服务器上下载代码,编译并发布到各个stage server上。

横向扩展
所有系统必须可以通过多进程部署的方式进行扩展。 这就要求:

  1. 所有系统可以运行在一个或多个进程中。 但所有进程必须是无状态的,进程之间是无共享的。 对于Web来说,特别注意避免依赖session。如有需要,session需保存在membcached或者redis等内存缓存中。
  2. 所有进程运行时动态绑定到端口来提供服务。
  3. 避免使用守护进程或者PID文件。

同构环境

确保开发、测试和线上环境的同构。这包括如下内容:

  1. 各stage下所使用的操作系统环境是一致的。
  2. 各stage下所使用的容器是一致的,包括JVM版本、容器版本;
  3. 各stage下所使用的数据库及其版本是一致的。
  4. 测试和线上环境可以在部署实例数量上不同,但在测试环境中,对于每个系统,至少部署2个实例。
  5. 各个stage下的唯一差异是通过配置参数来控制的。

随着基础设施的完善,我们补充了如下原则:

配置参数
与环境相关的配置信息,必须与代码严格分离,包括数据库、第三方证书、域名、和性能有关的配置(线程数、重试间隔等)。配置信息统一使用环境变量来存储。

幂等原则
所有的接口必须实现为幂等的,这包括:

  1. 该接口在同一个server上可以多次调用;
  2. 如果某一个server上调用出现网络问题,客户端可以进行重试并将请求转发到另一个server上执行。

启动关闭
每个系统需提供启动、关闭和验证脚本。

  1. 系统在启动时执行必要的环境检查,包括不得使用root账户来启动应用、端口是否被占用等。
  2. 启动成功后,可以通过验证脚本来确认运行状态。
  3. 关闭脚本必须能够优雅终止进程,这包括回退所有的连接、停止接收消息,完成所有待处理的消息,必要时执行回滚等操作。

收集日志
所有日志信息都必须通过终端收集到日志服务器上。

监控报警
所有线上运行的系统,必须配置监控和报警,并落实报警处理人员。

制定规范

在原有的

  1. Java编码规范

的基础上,针对本次技改,我们又制定如下规范:

  1. 支付系统监控报警规范。在支付系统的监控与报警 一文中有介绍。
  2. 支付系统Restful 接口设计规范。
  3. 支付系统RPC接口设计规范。 在微服务与RPC一文中有介绍。

这些规范在执行过程中也会不断地进行补充和调整。除了在code review中确保这些规范被落地执行外,每周周会也会对异常执行情况进行分析,确保规范制定是符合实际需求的,并能够与时俱进地进行调整。 当然,最重要的规范,是软件过程的规范:

  1. 支付系统开发的软件过程规范。在微服务开发的软件过程一文中有详细介绍。

团队建设

微服务架构是否能够顺利实施,离不开团队成员的支持,以及团队能力的提升。团队建设一直是整个技改过程的重中之重。 团队建设本身是一个大话题。这里重点介绍我们在团队分工上的工作。

团队的分工和整个架构设计需保持一致(又是康威定律)。在架构设计上,我们采取的整体策略,是参考原有的SSH架构,将业务逻辑和接口实现分离,将进程内调用改造成进程外调用,并在此基础上做切分。 这样,在团队划分上,前期,是按照层来分工,分为如下三个小团队:

  1. 接口服务团队,开发对外的接口,对接业务系统以及Android,IOS,PCWeb等各端。随着业务的发展在,这个团队也会逐步按照端来进一步分解。
  2. 基础服务团队,为对外接口提供业务逻辑服务。这也是最大的一个团队,随着业务的发展,这个团队也会逐步按照业务进行拆分,分裂成账户、支付、交易等小团队。
  3. 基础设施团队,负责支持上述工作的各种规范的制定,以及支持这些规范实现的基础设施。

感谢您对本文的关注,如需要及时收到凤凰牌老熊的最新作品,或者有相关问题探讨,请扫码关注“凤凰牌老熊”的微信公众号,在公众号里留言或者回复,可以尽快处理,谢谢。

本文欢迎转载,转载时请注明本文来自 微信公众号“凤凰牌老熊”。