随着系统改进工作的进行，一些架构性的问题也越来越突出。在开发中，一个遗留接口是否要迁移到微服务架构上，哪些接口应该放到同一个项目上，项目应该如何组织，日志、监控等基础性的工作应该怎么统一规划，都需要从架构的层面来进行设计。
确定目标
公司每一年都会有一个明确的战略目标，这个目标最终会被分解到每个业务上去实施。 对于支付业务，我们的目标是：
持续提升支付成功率
支付成功率是支付业务的最高衡量指标。提升成功率的首要措施是提升系统的稳定性，在此基础上，通过简化支付流程、优化支付路由等措施，提升转化率。
持续降低支付成本
在保证支付的稳定的前提下，引入更多底成本的渠道，通过支持渠道优惠活动等措施，来降低支付成本。
支持进入新市场
配合公司的市场拓展需求，为新市场提供支付支持。
制定原则
为了和目标保持一致，我们制定了一些微服务的架构规则。当然，这些规则也是随着团队的进步、业务的变更做调整。 我们的原则是参考Heroku的12 Factor而制定的。
以下原则是在刚启动微服务架构改进的时候制定的。
虚机开发
所有开发工作必须在虚机上进行，不得使用个人物理机开发。这使得开发人员能够随时在任何地方调起开发环境，避免由于环境配置问题而影响问题修复。
版本控制
使用Git做版本控制。 每个项目都有一个基准代码库，部署时从主干获取代码。上线时对主干打Tag，每个Tag对应一个线上可执行代码。 测试环境、预部署环境和线上环境都使用相同的基准代码。
代码审核
为了保证代码质量，所有代码必须通过至少两位工程师的审核才可以签入到主干版本中。执行日常代码审核，避免在部署前进行突击式审核。
自动部署
开发人员不得直接将开发机上的构件推送到测试、线上环境。 build, release和run必须分离。 自动部署系统（Jenkins）将从版本控制服务器上下载代码，编译并发布到各个stage server上。
横向扩展
所有系统必须可以通过多进程部署的方式进行扩展。 这就要求：
所有系统可以运行在一个或多个进程中。 但所有进程必须是无状态的，进程之间是无共享的。 对于Web来说，特别注意避免依赖session。如有需要，session需保存在membcached或者redis等内存缓存中。
所有进程运行时动态绑定到端口来提供服务。
避免使用守护进程或者PID文件。
同构环境
确保开发、测试和线上环境的同构。这包括如下内容：
各stage下所使用的操作系统环境是一致的。
各stage下所使用的容器是一致的，包括JVM版本、容器版本；
各stage下所使用的数据库及其版本是一致的。
测试和线上环境可以在部署实例数量上不同，但在测试环境中，对于每个系统，至少部署2个实例。
各个stage下的唯一差异是通过配置参数来控制的。
随着基础设施的完善，我们补充了如下原则：
配置参数
与环境相关的配置信息，必须与代码严格分离，包括数据库、第三方证书、域名、和性能有关的配置（线程数、重试间隔等）。配置信息统一使用环境变量来存储。
幂等原则
所有的接口必须实现为幂等的，这包括：
该接口在同一个server上可以多次调用；
如果某一个server上调用出现网络问题，客户端可以进行重试并将请求转发到另一个server上执行。
启动关闭
每个系统需提供启动、关闭和验证脚本。
系统在启动时执行必要的环境检查，包括不得使用root账户来启动应用、端口是否被占用等。
启动成功后，可以通过验证脚本来确认运行状态。
关闭脚本必须能够优雅终止进程，这包括回退所有的连接、停止接收消息，完成所有待处理的消息，必要时执行回滚等操作。
收集日志
所有日志信息都必须通过终端收集到日志服务器上。
监控报警
所有线上运行的系统，必须配置监控和报警，并落实报警处理人员。
制定规范
在原有的
Java编码规范
的基础上，针对本次技改，我们又制定如下规范：
支付系统监控报警规范。在支付系统的监控与报警 一文中有介绍。
支付系统Restful 接口设计规范。
支付系统RPC接口设计规范。 在微服务与RPC一文中有介绍。
这些规范在执行过程中也会不断地进行补充和调整。除了在code review中确保这些规范被落地执行外，每周周会也会对异常执行情况进行分析，确保规范制定是符合实际需求的，并能够与时俱进地进行调整。 当然，最重要的规范，是软件过程的规范：
支付系统开发的软件过程规范。在微服务开发的软件过程一文中有详细介绍。
团队建设
微服务架构是否能够顺利实施，离不开团队成员的支持，以及团队能力的提升。团队建设一直是整个技改过程的重中之重。 团队建设本身是一个大话题。这里重点介绍我们在团队分工上的工作。
团队的分工和整个架构设计需保持一致（又是康威定律）。在架构设计上，我们采取的整体策略，是参考原有的SSH架构，将业务逻辑和接口实现分离，将进程内调用改造成进程外调用，并在此基础上做切分。 这样，在团队划分上，前期，是按照层来分工，分为如下三个小团队：
接口服务团队，开发对外的接口，对接业务系统以及Android，IOS,PCWeb等各端。随着业务的发展在，这个团队也会逐步按照端来进一步分解。
基础服务团队，为对外接口提供业务逻辑服务。这也是最大的一个团队，随着业务的发展，这个团队也会逐步按照业务进行拆分，分裂成账户、支付、交易等小团队。
基础设施团队，负责支持上述工作的各种规范的制定，以及支持这些规范实现的基础设施。
感谢您对本文的关注，如需要及时收到凤凰牌老熊的最新作品，或者有相关问题探讨，请扫码关注“凤凰牌老熊”的微信公众号，在公众号里留言或者回复，可以尽快处理，谢谢。
本文欢迎转载，转载时请注明本文来自 微信公众号“凤凰牌老熊”。
