原文章:
https://www.cnblogs.com/xiaoliangyuu/p/13234039.html
第20章 微服务架构 264
1、微服务架构产生的历史背景:
1、代码重复率高。进而导致需求变更困难、代码维护困难
2、部署效率低。2.1一个小功能的变更导致打整个war包 2.2编译时间长 2.3测试工作量大
3、由于以上原因，导致新需求上线周期长
2、微服务架构带来的改变:
1、应用解耦
2、分而治之:水平拆分、垂直拆分
3、敏捷交付。敏捷性的产生，是将运行中的系统解耦为一系列功能单一服务的结果
3、微服务划分原则:单一职责原则，简单的、原子的微型服务，专注于做一件事
4、开发微服务:
5、基于docker容器部署微服务:
1、docker优势:快速(性能)和可移植性
2、docker的4个优点:
1、线上和线下环境等同性(容易排查线上bug；相对于虚拟机占用资源少，可在开发环境模拟)
2、与特定的云提供商解耦
3、提升运维效率。docker是标砖化容器，在任意环境实现统一的部署体验
4、敏捷性。秒级扩容
6、治理和运维微服务
微服务导致运维成本大幅提高，服务拆分粒度越细，运维和治理成本就越高。
主要方案为 分布式和自动化。
1、分布式如:分布式性能数据采集、分布式日志检索、分布式报表展示。
2、自动化就是将以前人工操作的运维工作逐步标准化、流程化和规范化。如自动扩容
7、微服务优点总结:
1、开发、测试和运维简单
2、局部修改很容易部署，有利于持续集成和持续交付
3、技术选择更灵活，不与特定语言和工具绑定
4、有利于小团队作战，敏捷交付
第21章 服务化最佳实践 280
1、远程服务调用相对于本地调用会有性能和时延问题:
1、客户端对消息序列化，服务端反序列化，会占用cpu资源
2、序列化时需要创建二进制数组，占用jvm堆内存或堆外内存
3、客户端发送请求消息和接受反馈消息，占用网络带宽
2、远程服务调用性能影响因素有3个:
1、I/O调度模型:同步阻塞I/O(BIO)还是非阻塞IO(NIO)
2、序列化框架的选择:文本协议、二进制协议或压缩二进制协议
3、线程调度模型:串行调度还是并行调度，锁竞争还是无锁化算法(高性能的Reactor线程模型)
3、netty优势总结(详见书):零拷贝、内存池、无锁化的串行设计、高效的并发编程
4、序列化框架的影响因素:
1、序列化后的码流大小(网络带宽的占用)
2、序列化&反序列化的性能(CPU资源占用)
3、是否支持跨语言(异构系统的对接和开发语言切换)
4、并发调用的性能表现:稳定性、线性增长、偶现的时延毛刺等
5、服务化高性能实践总结:
1、合理设置线程池线程个数。因为JDK的线程池默认采用N个线程争用一个同步阻塞队列方式，过多的线程数会导致激烈的锁竞争，导致性能下降
2、尽量减小传输码流的大小，无用的字段尽量不要传输
3、设置合适的客户端超时时间，防止业务高峰期多个线程排队，占用服务器资源
4、核心服务与非核心服务做隔离
5、尽量使用Docker，而不是虚拟机。避免虚拟化导致的超过20%的性能损耗
6、设置合理的服务调度优先级，并根据线上性能监控数据做实时调整
6、分布式事务:
本地服务时，多个sql可以放在一个事务块中，如果有异常，则全部进行回滚。而服务化之后，多个sql分散在了多个服务中，事务性无法保证。
服务化之后事务不一致主要是由服务分布式部署导致的，因此也被称为分布式事务问题
设计方案:两阶段提交
其他:在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性，尽量避免使用分布式事务
7、研发团队协作问题:
1、共用服务注册中心。正在开发的服务不可以发布到注册中心
2、2.1 前向兼容性规范指定。 2.2 支持新增、删除、修改字段 2.3 字段定义位置无关性 2.4 码流支持乱序