------------------------------------------------------------------

为什么微服务如此流行?

01.敏捷出现之路

 

 

 

所谓的架构和管理，都是需求所驱动的。

 

02.多重因素要求企业具备整体敏捷力

 

 

 

 

03.DevOps、敏捷、微服务于云原生应用

 

 

 

技术在不断演进革新

 

 

 

 

 

挑战：高度分散和异构化的IT运维环境

 

 

 

持续交付的挑战：软件开发中的三级耦合

 

 

 

代码耦合：一个开发人员的修改即可影响整个系统团队<20

组件级耦合：延迟影响至运行时，多团队协作成为可能；接口定义不通过用，无法跨技术栈使用

服务级耦合：延迟影响至生产环境对团队，多技术栈协作成为可能接口现实定义，服务自治

 

--------------------------------------------------------------

微服务架构的定义？

为实现企业敏捷能力，工程上的持续解耦一定会造成系统架构和运维的复杂

微服务和容器化，成为企业在工程上支持敏捷的必要选择!

一套服务:业务职能   /单一职责   /去中心化   /轻量级进程间通讯   /独立部署，独立进程

 

 

 

组织解耦:康威定律

康威指出:系统设计受限于组织自身的沟通结构

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

第二定律：时间再多一件事情也不可能做得完美，但总有时间昨晚一件事情

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

第三定律：大的系统组织总是比小系统更倾向于分解

“系统设计受限于组织自身的沟通结构，组织规模越大，灵活性就越越差，这种现象也就越明显”

 

互联网应用——定义了微服务

 

 

 

技术微中心的架构-->业务为中心的架构

 

 

 

 

 

 

--------------------------------------------------------------

软件架构的演进路径？

01.软件生命周期于架构演化

 

 

 

探索阶段：寻找产品和市场匹配点.产品需要整体快速迭代，过多的模块拆分指挥增加更多障碍。团队较少，协作问题不突出，不需要微服务架构。以手工测试为主。

扩张阶段：市场需求指数级增长。产品特性主键稳定，开始通过模块化提升单一特性的能力。团队开始扩展，协作问题涌现，开始进行微服务拆分。引入自动化测试保证一致性

收割阶段：产品稳定，最大化产品收益。产品特性应景稳定，对各模块的能力，性能等要求高。团队规模已经很大，必须采用微服务架构协助各各团队相对独立的继续宁运作。自动化测试识别任何改动引入的风险。

 

02.软件是人还是机器人