微服务是一种研发模式，不是开发里引入微服务框架即可，而是涉及整个开发周期。
最近在看《微服务治理》，顺便做下笔记，毕竟好记性不如烂键盘？
1. 单体架构
架构分层与组件库
最初在网站或者系统较小的时候，一般都是把所有功能模块打包一在一个工程直接部署。在我学生时期的大作业，或者刚工作时碰到功能较为简单或者访问量较小的网站之类就是如此。
- 设计模式使用MVC
- 实际开发通过框架(Framework)完成规范的约束
- 将通用功能模块抽离成功独立的通用组件库，解放业务开发人员对底层的关注。不过工程与组件库之间的依赖和组件库之间的依赖会组件形成网状关系，然后版本迭代进一步提升复杂度
不足
不过随着时间的推移，代码的不断迭代，整个工程终究会不断变成一个庞大的怪兽（如果一直活着）
- 单体应用庞大又复杂时，甚至开发人员都发生了变更，没有开发者对其有完全了解，这时候无论是修BUG还是功能迭代，都会变得十分谨慎，容易恶性循环，谁都不愿意优化或者改动过大，单纯堆砌直到重构
- 单体应用庞大影响启停速度，从而影响开发效率与线上变更
- 单体应用碰到资源冲突时难以扩展，比如不同模块可能是cpu密集型或者io密集型，或者内存型之类的，部署成本更高
- 最后就是尾大不掉，太大了，难以进行架构升级与技术优化
2. SOA
形式是服务总线（ESB）
- 传统中间件技术加通信协议
- 由老牌大厂主导，复杂，庞大
- 服务治理粗糙，人工比例大
不过我毕业后在互联网行业倒基本没怎么碰到过这个。
3. 分布式服务与治理
背景
- 互联网（xx敏捷开发)，版本迭代非常快
- 无论是网站还是应用，各个功能模块访问不均衡
随着发展规模壮大，按业务拆分服务
服务框架
轻量化SOA架构
- 引入服务注册发现机制与远程调用机制
- 服务负载均衡
- 限流，降级和熔断保护机制
将服务管控与运维能力下沉到框架层面，让业务开发者专注开发
分布式服务治理
- 服务度量
- 服务基础与管理信息
- 服务质量和服务能力（支持XXXqps）
- 服务依赖和服务调用统计
- 服务物理分布
- 服务管控
- 服务部署上下线
- 服务路由管控
- 服务限流，降级和熔断保护措施
- 服务授权（访问授权管理）
4. 微服务及治理
微服务是一种研发模式，不止技术
背景
- docker技术的出现，极大降级服务部署与运维成本
- 服务应用规模越来越大，服务粒度越来越小（比如单纯的缓存服务）
架构模式特点
- 高内聚，低耦合。 根据业务边界确定服务边界，符合领域驱动设计（DDD），专心完成一件不可再分割的完整业务操作功能，即为微服务
- 资源独享：像数据库资源便是独享，确保松耦合。不过会导致数据冗余，事务一致性也很麻烦
- 模式：
- 基于SDK的同构，由框架提供微服务一系列管控能力
- ServiceMesh(SideCar)，可以异构，sidecar就相当于一个透明代理，处理微服务路由与管控事情。
- 问题：
- 单点依赖：存在通用服务被大部分其他服务调用（比如来个鉴权服务跪了，所有依赖的相关服务涉及鉴权的业务都得）
- 循环调用：A->B->C->A
- 服务冗余： 存在微服务已不再使用
- 调用关系梳理：
- 静态代码调用链路分析
- 动态线上调用依赖关系分析
研发治理
-
小团队，小工程：不同微服务做好隔离，每个服务都是独立工程，提高各个工程的构建与部署效率；不要一个大工程，一个目录一个模块，CI构建不同微服务。（对于笔者实际工作经验来说，在开发某个应用的时候的确会出现这样的设计，原因应该就是多个工程创建繁琐，同一工程方便引用代码）
-
工程与代码质量治理：正常都是发生在业务快速迭代期间，功能迭代，时间紧和任务重。要不临时修改，要不严格按照规范执行。（如果没有强制约束，非常容易出现先用临时方案做出来，后续有空再重构！！！实际上只要没出问题，一般不会有空去重构的）
-
接口契约治理： 以接口形式提供内部功能，服务提供方需要确保变更不影响接口逻辑，或者保证变更能同步到调用方
-
测试治理：单元测试和冒烟测试需要Mock，但也有局限（工作量，无法模拟网络延时等）；集成测试对线上服务完备性依赖强
-
运维治理：服务集群节点规模大，调用层级多且复杂。需要对线上有完备的链路追踪与监控，能及时发现节点健康问题，进行修复或者资源调度；智能化运维（像笔者工作中便做过服务端日志智能归类平台，收集服务端日志，过滤清洗，归类统计与报警，减少程序工作量。）
-
管理治理：敏捷开发（毕竟微服务架构即是灵活快速）；Devops，运维自动化将部署运维监控与管理让渡给开发者。如书中图（微服务全生命周期管理）
以上单纯是看书学习时做的一点笔记，有问题欢迎指正。
参考
- 《微服务治理》（刚开始看这本书）