------------------------------------------------------------------
为什么微服务如此流行?
01.敏捷出现之路
所谓的架构和管理，都是需求所驱动的。
02.多重因素要求企业具备整体敏捷力
03.DevOps、敏捷、微服务于云原生应用
技术在不断演进革新
挑战：高度分散和异构化的IT运维环境
持续交付的挑战：软件开发中的三级耦合
代码耦合：一个开发人员的修改即可影响整个系统团队<20
组件级耦合：延迟影响至运行时，多团队协作成为可能；接口定义不通过用，无法跨技术栈使用
服务级耦合：延迟影响至生产环境对团队，多技术栈协作成为可能接口现实定义，服务自治
--------------------------------------------------------------
微服务架构的定义？
为实现企业敏捷能力，工程上的持续解耦一定会造成系统架构和运维的复杂
微服务和容器化，成为企业在工程上支持敏捷的必要选择!
一套服务:业务职能 /单一职责 /去中心化 /轻量级进程间通讯 /独立部署，独立进程
组织解耦:康威定律
康威指出:系统设计受限于组织自身的沟通结构
第一定律：组织沟通方式会通过系统设计表达出来
第二定律：时间再多一件事情也不可能做得完美，但总有时间昨晚一件事情
第三定律：线性系统和线性组织架构间有潜在异质同态特性
第三定律：大的系统组织总是比小系统更倾向于分解
“系统设计受限于组织自身的沟通结构，组织规模越大，灵活性就越越差，这种现象也就越明显”
互联网应用——定义了微服务
技术微中心的架构-->业务为中心的架构
--------------------------------------------------------------
软件架构的演进路径？
01.软件生命周期于架构演化
探索阶段：寻找产品和市场匹配点.产品需要整体快速迭代，过多的模块拆分指挥增加更多障碍。团队较少，协作问题不突出，不需要微服务架构。以手工测试为主。
扩张阶段：市场需求指数级增长。产品特性主键稳定，开始通过模块化提升单一特性的能力。团队开始扩展，协作问题涌现，开始进行微服务拆分。引入自动化测试保证一致性
收割阶段：产品稳定，最大化产品收益。产品特性应景稳定，对各模块的能力，性能等要求高。团队规模已经很大，必须采用微服务架构协助各各团队相对独立的继续宁运作。自动化测试识别任何改动引入的风险。
02.软件是人还是机器人
