一、微服务和应用现代化

1、时代的浪潮，企业的机遇和挑战

在互联网化+数字化+智能化+全球化的当今社会，IT行业也面临新的挑战：

• 【快】业务需求如“滔滔江水连绵不绝”，企业需要更快的交付
• 【变】林子大了，百色用户，企业需要提供更个性化、更精细、随时变化的服务体验
• 【巨】万川汇聚，一叶扁舟，企业需要处理浩如烟海般的请求与数据，同事确保平稳与准确

企业想要在竞争中取得优势，必须比对手更快地把产品推出市场；拥抱市场变化，随时快速地相应用户新需求；不断扩大用户规模，持续增加处理吞吐。如果不能在瞬息万变的市场情况下做出快速反应，那只能被远远地甩在身后。

2、新技术的出现，为微服务奠定了发展的基础

• 移动化、云计算、物联化，促进了新型业务模式创新，需要依赖技术和新平台
• 容器技术的出现，为服务多了以后如何自动化部署、如何运维提供了完美的解决方案，解决了微服务“最后一公里”落地的问题，从而完成了微服务生态最后一块拼图。
• Devops理念已逐渐被业界广泛接受，越来越多的企业开始践行Devops实施。Devops为微服务的开发、测试及运维的自动化提供了坚实的基座。

3、新时代IT行业面临的四个变化

• 用户行为的变化：业务应用的用户访问不可预估，突发性访问增多，微博事件和小红书海外流量突然激增就是最好的案例
• 业务模式的变化：所有业务访问都是通过互联网渠道，包括Web、手机APP、微信小程序等
• 业务系统开发的变化：应用再也不像以前半年/一年进行规划，随时会有需求变化，两周一个迭代成为常态。业务应用交付周期短，质量要求高
• 运维模式的变化：要求全天候值守，在线升级和快速响应。不同团队特别是外包团队使用不同的技术栈，无法统一管控

因此，我们评估是否需要采用微服务架构，往往考察这五大关键条件：

• 数据量和业务复杂度
• 团队规模
• 应对业务流量变化
• 是否需要足够的容错容灾
• 功能重复度和差错成本

二、服务理论基础与设计原则

什么是微服务？
一起合作的独立小服务单元

1、微服务理论基础——康威定律

组织形式等同系统设计——设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构

• 第⼀定律：Communication dictates design（组织沟通⽅式会通过系统设计表达出来）
• 第⼆定律：There is never enough time to do something right, but there is always enough
  time to do it over（时间再多⼀件事情也不可能做的完美，但总有时间做完⼀件事情）
• 第三定律：There is a homomorphism from the linear graph of a system to the linear graph
  of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）
• 第四定律： The structures of large systems tend to disintegrate during development,
  qualitatively more so than with small systems（⼤的系统组织总是⽐⼩系统更倾向于分解）
  

第⼀定律：组织沟通⽅式会通过系统设计表达出来

5个⼈的项⽬组，需要沟通的渠道是 5*(5–1)/2 = 10
15个⼈的项⽬组，需要沟通的渠道是15*(15–1)/2 = 105
50个⼈的项⽬组，需要沟通的渠道是50*(50–1)/2 = 1,225
150个⼈的项⽬组，需要沟通的渠道是150*(150–1)/2 = 11,175

⼈与⼈的沟通是⾮常复杂的，⼀个⼈的沟通精⼒是有限的，所以当问题太复杂需要很多⼈解决的时候，我们需要做拆分组织来达成对沟通效率的管理

在团队内部进⾏频繁的、细粒度的沟通。对于团队外部，定义好接⼝，契约，只进⾏粗粒度的沟通。这样可以降低沟通成本，同时也符合⾼内聚，低耦合原则

第二定律：时间再多⼀件事情也不可能做的完美，但总有时间做完⼀件事情

复杂的系统需要通过容错弹性的⽅式持续优化，不要指望⼀个⼤⽽全的设计或架构，好的架构和设计都是慢慢迭代出来的

复杂系统包括但不限于以下模块：

• 持续集成
• 敏捷开发
• 弹性伸缩
• 监控告警
• 灰度发布
• 熔断隔离

拥抱变化，解决当下，先完成一个一个小目标

第三定律：线型系统和线型组织架构间有潜在的异质同态特性

你想要什么样的系统，就搭建什么样的团队，反之亦然。

第四定律：合久必分，分而治之

⼀个⼤的组织因为沟通成本/管理问题，总为被拆分成⼀个个⼩团队（2 pizza team）

2、微服务的标准

通过康威定律可以得出行为标准：

• ⽤⼀切⼿段提升沟通效率。能2个⼈讲清楚的事情，就不要拉更多⼈，每个⼈每个系统都有明确的分⼯，出了问题知道⻢上找谁，避免踢⽪球。
• 通过MVP（最⼩化可实⾏产品，Minimum Viable Product）的⽅式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。
• 你想要什么样的系统设计，就架构什么样的团队。最好按业务来划分团队，让团队⾃然⾃治内聚，明确的业务边界会减少和外部的沟通成本。
• 做⼩⽽美的团队，⼈多会带来沟通的成本，让效率下降。

从而得出微服务的核心标准：

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• 去中心化
• 自动化运维（Devops）
• 容错
• 快速演化

3、微服务设计战略

三、微服务改造

1、微服务架构VS单体架构

2、微服务架构面临的挑战

• 运维要求较高：需要保证几十甚至几百的微服务的正常运行与协作，给运维带来很大的挑战
• 分布式固有的复杂性：系统容错、网络延迟、分布式事务等问题需要解决
• 接口调整成本高：修改一个微服务的API，可能需要所有使用该接口的微服务做出调整
• 可能得重复劳动：多个微服务可能使用相同的功能，但功能本身并没有达到可以分解成微服务的程度，从而导致代码重复

3、如何改造

改造路径：

微服务与微服务平台

单体架构的微服务化