基于大数据与云计算的微服务如何运作.pptxVIP

微效劳，你玩的起吗？-?勿在浮沙筑高台

-MartinFowler微效劳架构 微效劳架构是?一种架构模式，它提倡将单?一应?用程序划分成?一组?小的效劳，效劳 之间互相协调、互相配合，为?用户提供最终价值。每个效劳运?行在其独?立的进程 中，效劳与效劳间采?用轻量级的通信机制互相沟通〔通常是基于HTTP协议的 RESTfulAPI〕。每个效劳都围绕着具体业务进?行构建，并且能够被独?立的部署到 ?生产环境、类?生产环境等。另外，应当尽量防止统?一的、集中式的效劳管理机 制，对具体的?一个效劳?而?言，应根据业务上下?文，选择适宜的语?言、?工具对其进 ?行构建。

为什么要采?用微效劳架构？

-RebeccaParsons让系统尽可能快的响应变化！初衷

?效劳足够小??独立运行??轻量级通信机制??独立的部署??去中心化?要多小？??怎么部署？??出错怎么办？??如何保证一致性

Tallenough玩得起微效劳的条件 快速响 服 务 ?自 演 进 持续改进的?自组织?文

2012年初探微效劳2014年?黑暗时代2015年效劳治理2016年新的征程背景介绍 2009年

业务系统B2012年新的需求 业务系统A

领域效劳重?用效劳 新的业务系统A业务系统B 模块A 模块B 模块C 模块D重复？ 业务系统A 模块A 模块B 模块C

领域效劳效劳A效劳C效劳B效劳D业务系统B效劳E效劳F微效劳架构初步形成 Librarian 业务系统A

那时的微效劳系统集成消除重复 ful APIRestfulAPI?自动化部署特性团队

它给我们带来了哪些好处？

领域效劳效劳A效劳C效劳B 效劳D新业务C三个?月上线 Librarian业务系统B业务系统C 效劳F效劳G 效劳E效劳H业务系统A

你是我们?见过最棒的团队！

更多效劳更快?一点？

效劳越来越多，周期越来越短 60*6services8*4services

12014年问题倍出 环境?手?工维护，频频出错部署成功率很低，部署时经常有?一堆环境修改需求，运维?人员出错时机增加，运维效率极低。2缺乏有效监控?无法快速有效定位问题，?无法快速有效知晓效劳运?行状态，效劳资源浪费。

3效劳过?大，堵塞交付快速增?长的结果导致效劳过?大或者效劳过?小。?而过?大的效劳导致整个提交流?水线堵塞，测试?人员?无法拿到新的版本，交付延期4团队出现冲突，架构腐化严重 交付不能完成导致各?角?色间的 冲突越来越严重，为了快速上 线质量遭到牺牲。架构?无?人守 护，各种不?一致性，效劳内部 接?口?一?片混乱，核?心?人员离职。2014年问题倍出〔?二〕

不要再添加任何效劳！

当然不是！

业务迅速扩张

技术选型灵活

助?力客户快速占领市场

那怎么办？

DevOps2015年效劳治理 快速响应只有这些是不够的 ful APIRestfulAPI?自动化部署特性团队

123效劳过?大，堵塞交付快速增?长的结果导致效劳过?大或者效劳过?小。?而过?大的效劳导致整个提交流?水线堵塞，测试?人员?无法拿到新的版本，交付延期4团队出现冲突，架构腐化严重交付不能完成导致各?角?色间的冲突越来越严重，为了快速上线质量遭到牺牲。架构?无?人守护，各种不?一致性，效劳内部接?口?一?片混乱，核?心?人员离职。 环境?手?工维护，频频出错部署成功率很低，部署时经常有?一堆环境修改需求，运维?人员出错时机增加，运维效率极低。缺乏有效监控?无法快速有效定位问题，?无法快速有效知晓效劳运?行状态，效劳资源浪费。回到问题

1.运维?自动化1 根底设施?自动化实施了新的部署流程，成功率?大?大提?高，部署时间缩短到30分钟。2?高效监控效劳提供状态汇报，利?用Splunk聚合?日志，对效劳运?行状态进?行监控，?大?大提?高运维效率。

2.DevOps?一家3效劳过?大，堵塞交付快速增?长的结果导致效劳过?大或者效劳过?小。?而过?大的效劳导致整个提交流?水线堵塞，测试?人员?无法拿到新的版本，交付延期4团队出现冲突，架构腐化严重交付不能完成导致各?角?色间的冲突越来越严重，为了快速上线质量遭到牺牲。架构?无?人守护，各种不?一致性，效劳内部接?口?一?片混乱，核?心?人员离职。缺乏有效监控?无法快速有效定位问题，?无法快速有效知晓效劳运?行状态，效劳资源浪费。回到问题 环境?手?工维护，频频出错 部署成功率很低，部署时经常 有?一堆环境修改需求，运维?人 员出错时机增加，运维效率极 低。

3.效劳拆分

微效劳的附加本钱

3.效劳?自演进1划分适宜的业务边界 22进?行适宜模块化 3可测试的4拒绝跨上下?文的数据