重构中的内部准备工作

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

确定目标

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

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

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

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

制定原则

为了和目标保持一致，我们制定了一些微服务的架构规则。当然，这些规则也是随着团队的进步、业务的变更做调整。 我们的原则是参考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下的唯一差异是通过配置参数来控制的。

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