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

确定目标

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

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

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

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

制定原则

为了和目标保持一致，我们制定了一些微服务的架构规则。当然，这些规则也是随着团队的进步、业务的变更做调整。 我们的原则是参考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. 基础设施团队，负责支持上述工作的各种规范的制定，以及支持这些规范实现的基础设施。