soso网站提交入口站长素材音效
一、微服务和应用现代化
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、如何改造
改造路径：
微服务与微服务平台
单体架构的微服务化
