1.重构中的外部准备技改是任何时候的敏感话题。大量问题需要解决，天时地利人和。1、适时就是选择合适的时机进行技术改造。在时间上，我们经历了三个阶段。（1）空闲时间开发企业应用，技术提升也是常有的工作。企业应用开发的特点是有忙有闲。版本发布前，紧锣密鼓地进行开发工作；老版本发布后，新版本的开发才刚刚开始，有比较空闲的时间进行技术改进。但是当这套方法搬到互联网应用开发中时，发现基本行不通。互联网应用开发有两种情况：很忙和很忙。预留大量时间用于技术改进几乎是不现实的。如果有一个业务可以有空闲时间做技术上的改动，那基本上就没必要改了，因为这也意味着这个业务进入了一个稳定和下降的时期。(2)按需改进由于没有空闲时间，另一种选择是按需改进，即在项目开发过程中改进涉及的模块。在实践中，我们也发现这种做法难度很大。遗留系统的模块依赖性通常令人难以置信。在改进过程中，经常会发现需要对依赖的底层模块进行较大的调整，导致改进工作无法进行。即使依赖模块没有问题，改进工作也会导致更多的时间开销，2~3倍是正常的。这种延迟不是所有项目都能承受的。(3)优化团队更适合互联网应用开发。成立专门的技术改进小组。约30%的开发能力用于技术改进。这些人可以致力于架构改进，也可以从项目团队中轮换。改善前先制定改善计划，循序渐进。当涉及到具体模块的改进时，会派出负责该模块的技术人员参与。如果模块改进和业务开发工作是同时进行的，可以考虑将两项工作结合起来。技改不能一蹴而就，也不能一蹴而就。这是一个连续的过程，按顺序接近，没有中断。项目紧张时，选择风险低的任务执行，少安排重构点。项目松的时候，重构核心接口，多安排重构。但不要打扰。一旦被打断，结果往往是没有人愿意继续。重构往往是前人栽树，后人乘凉的事情。风险大，短期内看不到效果。每个人都在做，也经常放弃。所以持续改进是必须的，避免半途而废。还有一点大家容易忽略。对于一个特别注重绩效、以产出衡量工作结果的团队来说，一定要果断避开绩效考核这个敏感期。2、地理优势所谓地理优势，从软件的角度来说，主要是指基础设施的建设。在完善现有系统、推广微服务架构之前，需要评估当前的基础设施建设是否能够满足要求。服务所需的基础设施包括：(1)不同服务在虚拟机环境或docker中的在线压力和运行环境要求不同，对内存、CPU、磁盘的要求也不同。根据服务需求自动弹性地创建所需的环境是微服务部署的前提。(2)版本控制软件版本控制不仅是为了协调人与人之间的协作，还要保证上线运行的系统一定是最终的正式版本。如果出现问题，开发人员可以从版本控制服务器下载一致的代码。现在一般都是用git来实现的。为什么不用SVN？网上对比文章很多，不是本文重点。(3)代码审查软件每个微服务作为一个独立的项目开发，统一编码标准，审查代码逻辑等，在这个场景下还是很重要的。兼容git，gitlab是首选的codereview软件。(4)集成发布集群是微服务必不可少的基础环境。需要将一个服务部署到几十台甚至上千台机器上。在这种情况下，手动部署是不现实的，依靠集成发布环境来实现版本获取、集成编译、旧版本备份、新版本发布、服务启动、服务暂停、服务重启。推荐詹金斯。(5)系统监控和监控自动化也是必要的基础设施。业务高峰期的问题告警和核心业务监控，都需要借助监控系统来解决。推荐Zabbix。(6)日志分析排查错误和审查系统，日志处理是不可避免的。如果要跟踪某个ID用户的行为，在上百台机器上一个一个查看日志是不现实的。使用ELK等工具将日志收集到存储中，提供查看日志的检索功能，甚至对日志进行统计分析也是必备的设施。(7)办公环境不用说，新老系统开发人员要协同工作，随时沟通。如果条件达不到，至少要建立顺畅的沟通方式，比如QQ群、微信群等。邮件不是个好选择，电话会议也不错。3.人和最重要的因素。总的来说包括三个方面：上级领导的支持、团队成员的认可、合作部门的理解。（一）上级支持毋庸置疑，上级的支持是先决条件。重构是一项高风险的工作，往往不容易马上产生新的成果，而且需要额外的投入。几个月来，没有什么新鲜事，出货量放缓，没有别的，重构或放缓。从公司层面，上级可以知道什么时候进行重构工作是合适的。公司即将调整架构，系统即将停产，近期有大事需要扶持，有些人需要尽快出成果提拔……都需要仔细评估是否可以进行重构，而这些东西，级别越高掌握的信息越多，所以得到他们的支持是必须的。(2)对团队成员的认可是对团队成员的认可。尤其对于遗留系统的开发者来说，他们的认可和毫无保留的支持是必要条件。他们最清楚系统的坑，哪些是必须改的，哪些是无用的功能，哪些只是临时解决方案。只有这样，才能在功能迁移时进行有目的的调整。2、重构的内部准备随着系统完善的推进，一些结构性问题也越来越突出。在开发中，遗留接口是否应该迁移到微服务架构，哪些接口应该放在同一个项目中，项目应该如何组织，日志、监控等基础任务如何统一规划，都需要从架构层面考虑。来设计。1、确定目标公司每年都会有一个明确的战略目标，这个目标最终会分解到各个业务去执行。对于支付业务，我们的目标是：（1）不断提高支付成功率支付成功率是衡量支付业务的最佳标准。提高成功率的首要措施是提高系统的稳定性。在此基础上，可以通过简化支付流程、优化支付路径来提高转化率。（二）继续降低支付成本在确保支付稳定的前提下，引入更多低成本渠道，通过支持渠道优惠活动等措施降低支付成本。（3）支持进入新市场，满足公司市场拓展需要，为新市场提供支付支持。2.原则为了与目标保持一致，我们制定了一些微服务架构规则。当然，这些规则也会随着团队的进步和业务的变化而调整。我们的原则是参考Heroku的12Factor制定的。在首次启动微服务架构改进时制定了以下原则。(1)虚拟机开发所有开发工作必须在虚拟机上进行，不允许使用个人物理机进行开发。这使得开发者可以随时随地调出开发环境，避免因环境配置问题影响修复问题。(2)版本控制使用Git进行版本控制。每个项目都有一个基线代码库，部署时从主干中获取代码。上线时Tag主干，每个Tag对应一个上线可执行代码。测试环境、预部署环境和生产环境都使用相同的基准代码。(3)代码审查为保证代码质量，所有代码必须通过至少两名工程师的审查，才能进入主版本。执行每日代码审查并避免在部署前进行未经通知的审查。(4)自动部署开发者不得将开发机上的组件直接推送到测试环境和线上环境。构建、发布和运行必须分开。自动部署系统（Jenkins）会从版本控制服务器下载代码，编译发布到各个阶段服务器。(5)横向扩展所有系统都必须通过多进程部署实现可扩展性。这就要求：所有的系统都可以运行在一个或多个进程中。但是所有的进程都必须是无状态的，进程之间没有共享的东西。对于Web，应特别注意避免依赖会话。如果需要，session需要存储在membcached或redis等内存缓存中。所有进程都在运行时动态绑定到端口以提供服务。避免使用守护进程或PID文件。(6)同构环境保证了开发、测试和线上环境的同构。这包括以下内容：每个阶段使用的操作系统环境是一致的。每个阶段使用的容器都是一致的，包括JVM版本和容器版本；每个阶段使用的数据库和版本是一致的。测试环境和真实环境的部署实例数量可能不同，但在测试环境中，每个系统至少部署2个实例。每个阶段下的唯一区别是由配置参数控制的。随着基础设施的完善，我们增加了以下原则：(7)配置参数和环境相关的配置信息必须与代码严格分离，包括数据库、第三方证书、域名、性能相关的配置（数量线程数、重试间隔等）。配置信息使用环境变量统一存储。(8)幂等性原则所有的接口必须实现为幂等的，包括：接口可以在同一台服务器上被多次调用；如果某个服务器调用出现网络问题，客户端可以重试并将请求转发给另一台服务器执行。(9)启动和关闭每个系统都需要提供启动、关闭和验证脚本。系统在启动时进行必要的环境检查，包括未使用root账户启动应用程序、端口是否被占用等。启动成功后，可以通过验证脚本确认运行状态。关闭脚本必须能够优雅地终止进程，包括回滚所有连接、停止接收消息、完成所有未决消息以及在必要时执行回滚。(10)收集日志所有的日志信息都必须通过终端收集到日志服务器上。(11)监控报警所有在线操作系统必须配备监控报警，并配备报警处理人员。3、制定规范在原有Java编码规范的基础上，针对本次技术改造，我们制定了如下规范：支付系统监控告警规范。在支付系统监控告警一文中有介绍。支付系统Restful接口设计规范。支付系统RPC接口设计规范。它在文章微服务和RPC中进行了介绍。这些规范将在实施过程中不断补充和调整。每周的周会除了保证这些规范在codereview中得到落实外，还会对异常执行情况进行分析，确保规范的制定符合实际需求，并能与时俱进。当然，最重要的规范是软件过程的规范：支付系统开发的软件过程规范。在微服务开发的软件过程一文中有详细描述。4、团队建设微服务架构能否顺利落地，取决于团队成员的支持和团队能力的提升。团队建设一直是整个技改过程的重中之重。团队建设本身就是一个大话题。在这里，我们专注于我们在团队划分方面的工作。团队的分工和整体架构设计需要保持一致（又是康威定律）。在架构设计上，我们采用的整体策略是参考原有的SSH架构，将业务逻辑和接口实现分离，将进程内调用转化为进程外调用，并在此基础上进行拆分。这样，在团队划分上，前期按层划分工作，分为三个小团队：接口服务组、对外接口开发、对接业务系统和Android、IOS、PCWeb和其他终端。随着业务的发展，团队会逐渐按端进一步分解。基础服务团队对外接口提供业务逻辑服务。这也是一个敬业的团队。随着业务的发展，这个团队会逐渐按照业务进行拆分，拆分成账户、支付、交易等小团队。基础设施团队负责制定支持上述工作的各种规范，以及支持这些规范实施的基础设施。【本文为专栏作者《凤凰牌老熊》原创稿件，转载请微信联系作者公众号《凤凰牌老熊》转载】点此阅读作者更多好文
