文档介绍：1
微效劳平台 技术可行性分析
名目
微效劳需求分析和架构设计 3
微效劳分布式事务处理 10
微效劳的价值 13
2
微效劳是目前最先进的开发方式，使用 spring clou用效劳，提高性能和可用性。
承受asynTemplate异步调用效劳，通过future猎取结果。，性能最优，google的grpc很棒。
依据业务的特点，机敏承受上面的方法调用效劳，有效地提升系统性能。
微效劳支持 OOD、DDD，依据业务场景而定架构模式，ODD 对于简洁业务应用适宜，对于简单的业务应用，承受面对领域设计 DDD 适宜，Axon 支持 DDD 的 CQRS 模式，和 spring cloud 一起开发。
承受 spring boot 开发功能、spring cloud ribbon 实现负载均衡、config 处理配置、zuul 做 api 网关、eureka 做效劳注册、histrix 限流、Sleuth 处理 log、dashbord、actuator、elk 监控、mysql 存储、rabbitmq 处理消息、redis 处理缓存、前端用 ngnix 实现负载均衡和缓存、rancher+k8s 实现docker 部署运行、太极框架处理分布式事务。
5
•简单度可控：在将应用分解的同时，躲避了原本简单度无止境的积存。每一个微效劳专注于单一功能，并通过定义良好的接口清楚表述效劳边界。由于体积小、简单度低， 每个微效劳可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
•独立部署：由于微效劳具备独立的运行进程，所以每个微效劳也可以独立部署。当某个微效劳发生变更时无需编译、部署整个应用。由微效劳组成的应用相当于具备一系列可并行的公布流程，使得公布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
•技术选型机敏：微效劳架构下，技术选型是去中心化的。每个团队可以依据自身效劳的需求和行业进展的现状，自由选择最适合的技术栈。由于每个微效劳相对简洁，当需要对技术栈进展升级时所面临的风险较低，甚至完全重构一个微效劳也是可行的。
•容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内集中，形成应用全局性的不行用。在微效劳架构下，故障会被隔离在单个效劳中。假设设计良好，其他效劳可通过重试、平稳退化等机制实现应用层面的容错。
6
•扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微效劳架构便表达出其机敏性，由于每个效劳可以依据实际需求独立进展扩展。
做微效劳架构设计规划，主要分为以下步骤：
•1整体架构设计
•2业务领域抽象、建模
•3效劳规划与层次划分、数据库设计与划分
•4效劳内流程、数据、契约〔接口〕定义和技术选型。
7
8
在根底交付设施自动化上，如以下图所示，表达在自动化、容器化交付这个流程中， 在平台化的背景下把团队思维转换为 DevOps 式的，依托 Docker 和 k8s 完成了 PaaS 平台的对接，同时和 QA 一起协作完成持续交付流程的建立。
9
基于对业务的抽象分解，在计算效劳层内部，就可以进展更加细分的层次规划，先是垂直拆分为呈现层、计算层、数据资源 3 大纵层，核心的计算层又细分为 3 个层次， 包括业务流程处理层，通过组装下层效劳完成功能；业务规律组件是自包含，跨产品线、高度复用的组件；下面公共效劳组件是一些通用效劳。然后水平划分为多个效劳簇。如以下图所示。
2. 微效劳分布式事务处理
目前微效劳事务解决方案有 3 个：一、结合MQ 消息中间件实现的牢靠消息最终全都性二、TCC 补偿性事务解决方案三、最大努力通知型方案第一种方案：牢靠消息最终全都性，需要业务系统结合 MQ 消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统把握 MQ 的消息状态其次种方案：TCC 补偿性， 分为三个阶段 TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。TRYING
10
阶段主要是对业务系统进展检测及资源预留 CONFIRMING 阶段是做业务提交，通过TRYING 阶段执行成功后，再执行该阶段。默认假设 TRYING 阶段执行成功， CONFIRMING 就肯定能成功。CANCELING 阶段是回对业务做回滚，在 TRYING 阶段中，假设存在分支事务 TRYING 失败，那么需要调用 CANCELING 将已预留的资源进展释放。第三种方案：最大努力通知型，这种方案