《后端技术面试 38 讲》学习笔记 Day 10
27 | 微服务架构：微服务究竟是灵丹还是毒药？
原文摘抄
Dubbo 应该说是借鉴了此前更早的 SOA 架构方案，即面向服务的体系架构。
Dubbo 在借鉴 SOA 架构的基础上进行了优化，抛弃了 SOA 一些不必要的规范约束，使用二进制协议进行服务注册与调用，执行效率和使用的简洁性都得到了极大提升。
Dubbo 架构和 SOA 架构一样，最核心的组件也是 3 个，分别是服务提供者、服务消费者和服务注册中心。
阿里微服务重构成功的另外一个重要因素是，即使在单体时代，war 包内的模块关系也还是比较清晰的。所以在重构微服务的时候，只需要对这些模块进行较小的改动，进行微服务部署就可以了。
微服务本身和业务强相关，如果业务关系没梳理好，模块设计不清晰，使用微服务架构很可能得不偿失，带来各种挫折。
心得体会
- 小孩是耍不好大刀的，微服务这把牛刀在庖丁手里才是神器。清晰的了解牛的身体构造，就像工程师对工程业务的理解，只有烂熟于心，下刀才不会砍在骨头上。
工作体验
- 在单体工程中，子工程（模块）的划分，一个工程里包的划分。紧贴业务调理，不混论，后续拆分微服务才会顺理成章。另外，有术上的技巧，就是通过接口编程，抽象的隔离，不要进行实现上的依赖，对工程脉络也很有帮助。
28 | 高性能架构：除了代码，你还可以在哪些地方优化性能？
原文摘抄
系统性能指标主要有响应时间、并发数、吞吐量和性能计数器。
性能计数器，指的是服务器或者操作系统性能的一些指标数据，包括系统负载 System Load、对象和线程数、内存使用、CPU 使用、磁盘和网络 I/O 使用等指标，这些指标是系统监控的重要参数，反映系统负载和处理能力的一些关键指标，通常这些指标和性能是强相关的。这些指标很高，成为瓶颈，通常也预示着性能可能会出现问题。
具体说来，整个测试过程又可细分为性能测试、负载测试、压力测试三个阶段。
数据中心优化:大型的互联网应用基本都采用多数据中心方案，在全球各个主要区域都部署自己的数据中心，就近为区域用户提供服务，加快响应速度。
硬件优化
操作系统优化:经过分析发现，在某些版本的 Linux 中，transparent huge page 这个参数是默认打开的，导致系统占用 CPU 过高。
虚拟机优化
基础组件优化
架构优化:缓存、消息队列、集群
代码优化
心得体会
- 这是从架构师角度去看的架构优化，也是公司级的架构师。从数据中心一直到代码层次。
- 性能优化真的知识面又广又深，工作四五年的我也只能是在某些方向略知皮毛。
工作体验
-
先说说听说的，在一个数据中心，服务器是不是在一个机架、传输的是不是万兆网卡都很影响大数据这样的集群跑批的性能。
-
jvm的参数调整可能是最贴近java工程师的，主要在于调整JVM内存的大小，以及GC算法的调整。工作目前来看，给不要太少的JVM，GC调整为G1垃圾回收器，正常压数个小时的压力测试，也不会出现FGC，已经很不错了。
-
然后是各种组件的调参，需要对我们用到的组件、中间件有足够的了解。例如tomcat连接数、线程数；redis的连接数、超时时间、空闲连接数等；feign的连接数，超时时间等配置都会影响性能。
-
然后是操作系统的调参，目前生产用的基本上都是redhat，也在其他公司看过centos，像ubuntu还未在生产上遇到过。操作系统的参数很多，没有听过那个参数我们可能根本没有去查看、调整他的思路。例如哪个参数限制socket连接数量，又哪个参数设置tcp自动断开的时间等等，都是需要学习+经验+遭遇才会慢慢习得的。不能急于求成，慢慢来吧。
-
另外，想起来以前其他吸引人的标题文章，例如“榨干服务器的每一分性能”，其实这个是一个比较可笑的做法。我们往往在机器的各种资源到达80%就进行轻微的告警，通知系统负责人，而一旦到90%，并保持一段时间，就生成一个严重的告警了。
服务器长期处于一个高压情况是一个危险的做法，进程存在被操作系统kill掉的风险，或者操作系统本身宕机。
这个指标指导我们在压测时，性能调优时，比较优秀的做法是将性能约束在75%-80%，可以偶尔超过85%（高峰刚过来的时候）。