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