在介绍这个过程之前，先强调一个观点：

• 人管代码，代码管机器
• 人管代码，代码管机器
• 人管代码，代码管机器

一、软件过程

Jira原是设计来进行Bug跟踪的系统，后来系统功能逐步完善后，被广泛适用于软件过程管理。Jira优势在于简单，好用。 这里就不介绍Jira的具体使用。 使用Jira进行软件项目管理，首先需要定义任务的处理流程。 以下是一个参考流程：

在这个流程中，需要区分两个概念：任务和子任务。 每个任务对应一个完整的业务需求，比如对账、对接工行借记卡、获取个人优惠券列表接口。这些业务需求每个都是可以独立测试的。子任务设置相对比较简单，每个子任务对应这在本次任务执行中需要修改的开发项目。 比如对接工行借记卡，会涉及到：

1. 支付网关项目调整；
2. 支付路由项目中增加路由选项；
3. 工行借记卡通道对接。

三个项目的修改，那会对应在这个任务下建立三个子任务。

• 任务是用来追踪项目过程的，这是项目经理和产品经理关注的层次。
• 子任务是用来支持开发自动化的，这是开发人员关注的层次。

这样，针对任务和子任务，会设置不同的属性：

1.1 需求管理

Jira也是一个不错的需求管理工具。产品经理可以通过Jira来执行需求管理，相对开发来说，需求管理流程会比较简单，一般是开发需求、审核需求、关闭需求三个环节即可。 需要注意的地方是：

1. 需求管理流程需要和开发流程分离，毕竟这是不同的团队做的事情。
2. 开发任务可以和需求任务相关联。Jira通过复制任务来提供这个支持。

一个需求任务可以对应多个开发任务，这在实际操作中是很常见的：

1. 为了满足上线要求，一个需求任务会被拆分成多个开发任务，先完成核心功能开发并上线，再完成外围功能开发。这两次独立上线的工作，会被拆分为2个或者更多的开发任务；
2. 如果对不同平台，比如Android、IOS、PCweb有不同的上线时间要求和技术需求，也需要将当前需求按照目标平台来拆分成开发任务。

1.2 创建任务

如上所述，开发任务的来源有两个：

• 需求任务，即对应产品经理提的需求；
• 优化任务，这一般是开发团队内部进行重构或者性能优化来提的开发任务。

那任务的粒度如何把握？ 每个开发任务是一个完整的需求，是可以独立执行测试和验证的。 每个任务开发周期控制在1个月以内。

1.3 创建子任务

在接收到开发任务后，开发人员需要对系统实现进行设计和分解，确定需要新开发的内容以及需要改进的工作。 在微服务架构中，一次任务开发会涉及到多个系统的变更。这样就需要为每个系统建立一个独立的子任务，以后，我们将按照这个子任务的设置来驱动开发流程。 每个子任务开发周期尽量限制2天以内，不能超过一周。

1.4 启动主任务开发

主任务启动开发流程比较简单，主要是邮件通知到各相关人员，可以启动该任务。

1.5 启动子任务开发

子任务的启动和执行，是整个流程的核心工作。

这里如果是使用git/gitlab来做版本控制，整个流程的要点在于：

1. 如果需要新建项目来开发，则由开发人员填写新项目的名称、类型（Web、RPC、工具类等），在Git上创建一个项目框架，包含必要的基础文件；
2. 邮件通知开发人员需要下载的项目代码库地址；
3. 开发人员签出代码到本地，执行开发工作；
4. 开发人员随时可以签入代码到服务器上，发出Merge Request；
5. GitLab在接受签入前，执行静态代码检查。静态代码检查的工具有FindBugs、PMD、Sonar等。 开发人员在开发时也必须自我进行静态检查，这里执行检查是避免开发人员漏查；
6. 执行单元测试；
7. 通知相关人员进行代码审核；
8. 执行代码审核；
9. 符合审核条件（如至少有2个人同意），审核通过， 代码被自动合并到主干版本。
10. 通知子任务可以提测。 当然，是否提测，是由开发人员来决定。

1.6 子任务和任务提测

子任务开发完成后，即可提测。子任务提测时，将触发Jenkins进行测试环境部署。

测试有两种方式：自动测试和人工测试。尽量采用自动测试，使得开发人员能够及时发现问题。

所有子任务完成后，主任务可以提测。主任务提测后，如果是人工测试，则测试人员介入开始执行测试任务；如果是自动测试，则开始运行集成测试脚本。

测试通过后， 既可以准备上线。

1.7 预部署和全部署

一般上线会分为两步，预部署和全部署。预部署的目的是先验证系统在线上环境运行是否正常，减少回滚成本。特别是在部署服务器特别多的情况下，先部署1-2台机器，可以在线上验证本次上线是否可以。 验证通过后，既可以执行全部署。

注意，预部署和全部署都是针对子任务而言。

少数公司会要求上线前进行审批，但这样做是不利于流程自动化的。 一天几十次上线，谁能知道这是不是可以上。 但有一点很重要，系统上线前，必须通知到相关的使用方。如果出现问题，使用方可以尽快知悉。

二、项目文件结构

开发参考目录结构：

从这个目录里面我们可以看到，和项目相关的部署用脚本，需要由项目开发人员自己来维护，用以保证部署工作能够自动执行。包括验证项目部署成功的脚本。

验证项目是否部署成功，一种方式是在日志中打桩，grep到这个日志，即意味着系统成功启动；一种方式是调用接口来验证是否成功。

部署目录参考：

总之，微服务项目的管理核心理念在于“自动化”，消除人为因素。人管代码，代码管机器，最终目标是要实现自动上线。 消除人工测试，取代以自动化测试；消除人工验证，取代以自动验证；消除人工部署，取代以自动化部署。 这样，再多的项目，也能够很好的进行管理。

前言

消息最终一致性是用于处理分布式事务解决方案之一，其中主要保证的目的是为了消息的可靠性，最终一致性，而可靠消息并不可靠，由于其它未知原因（如网络、宕机等），依然可能会造成消息的中断，发不出去的情况，就需要人工介入处理或者有一定的处理机制，所以在一定角度上来说，可靠消息在某一程度上，只是最大保障了消息的最终一致性，以为称“消息最终一致性”会更为合理。

以下为分析消息最终一致性，其中按的思路为ACID，即事务的主要特性。

传统事务处理

举例一个场景，以CURD事务举例，一个事务中有添加、删除、修改三个操作，这里我们且称添加为A，删除为B，修改为C，设置A，B，C为同步操作，则一个事务表示为（序号表示执行顺序）：

在这一事务中，可以用传统的处理方案处理，保证事务的一致性。

分布式事务处理

由于业务的发展，业务独立在一定程度上更好有效的解决了耦合，达到可扩展，组件化，高性能等，在服务化之后，我们继续使用上面的A、B、C来说明，假设已经分为A服务，B服务，C服务，实际的业务场景则为：

为了保证ACID，在A完成之后，一定要操作B服务，在B完成之后，一定要操作C，但实际中，网络、应用稳定性、异步调用等的不确定性，容易造成事务不统一，如A完成，在调用B时，由于网络或者其它原因，B并没有完成业务操作，同样，C 也没有完成，如下图：

以上的情况，这个事务并不统一，服务是独立的，要实现A回滚的操作，需要做更多的额外工作来处理。所以，为了确定B一定执行，在已完成的事务（如A）需要重复去调用或者有一种验证机制去确定B一定执行。

以上只是一种情况，可能出现多种情况。总之，打破了事务的ACID原则，而我们要做的就是尽最大努力确保这个ACID原则，即事务性。消息最终一致性的方案，为保持这个原则，做了一个保障方案。

消息最终一致性方案

注：可靠消息是一种基于消息中间件的包装，确保消息一致性的服务或者组件。

此方案中引入了可靠消息做为媒介，如图（序号表示执行顺序）：

在A完成之后，会一定去调用B服务，B服务一定会去调用C服务，确保一定会完成ACID的操作。

如果说事务失败，即在A失败，这部分可以在A服务内自己控制事务，包括异常处理等，就不会去调用B，此时，整个事务就不会进行。

回到之前的事务讨论

前面提过，添加为A，删除为B，修改为C，其中A，B成功，C操作失败，要不要做A、B回滚的处理？这个之前很多同事都有提问到。事务具有ACID特性，即整个事务来说，对消费方来说是透明的，要么成功，要么失败，A、B属于事务中的一部分，不会有回滚的操作，因为它会确保C一定去执行。

如果需要添加回滚，在程序上处理可实现，考虑到开发成本上，不太建议。如有更好的办法，也希望学习。

可靠消息对业务有一定的入侵性，并不能完全解耦，如在做幂等处理时，需要跟具体业务结合判断。

总结

针对以上可靠消息的特性及使用场景，在划分服务颗粒度上需按实际业务场景划分，以最简单的成本，解决最实际的问题。