5.13 华为DevCloud相关操作，微服务的简单理解

需求规划中的4层

Epic：战略举措，业务系统（例如：淘宝商城）

Feature：功能模块（例如：订单管理）

Story：拆分Feature，一个迭代内可交付的粒度（用户故事），它将作为迭代中的工作项。

Task：拆分Story，分成工作人员可以进行工时评估的工作粒度

通过测试管理界面右上的追溯试图创建测试用例，这样可以关联需求。

我们可以在测试用例中添加缺陷，添加后的缺陷将自动添加进Backlog（工作待办列表）中。

当我们通过git提交代码时可以fix用户故事中的编号，来完成这个用户故事。

使用git时，我们一般会对不同的feature创建不同的分支，代码提交到这个分支中而不是master中，所以我们要对master分支进行保护，在分支和master进行合并时需要通过合并请求，审核通过后才可以进行合并。

 

微服务：

一个项目中有5个模块，当一个模块因为某些问题时，可能会拖累其他模块，使整体系统崩溃。

例如，这就是一个单体架构系统，用的传统的MVC架构，所有子模块都集成在一个笨重的JVM中，优点是便于管理，缺点也比较明显：1、项目臃肿，不便于维护 2、资源无法隔离，整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮 3、无法灵活扩展，上述情况我们只需要对小绿负责的模块进行水平扩展（部署机群），但是单体架构只能对系统整体扩展。

微服务定义：简而言之，微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务特点：1、独立部署，灵活扩展  2，资源的有效隔离：每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。3、团队组织架构改变：传统架构的团队是水平架构，而微服务采用垂直架构（这种垂直划分只是一个理想的架构，实际中并不会把团队组织架构拆分得这么绝对。）

                  

微服务的缺点：1、项目有多个独立工程，开发和测试复杂度增加（拆分越细越复杂） 2、为了保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战。

微服务理解：将系统按照业务功能拆分成不同的模块进行开发，每个模块都是一个服务，是独立的进程，可以使用不同的技术来实现。