周志明老师出版过八部计算机技术书籍，其中《深入理解 Java 虚拟机》非常出名，在2020年整理了一份30多万字的《凤凰架构》，比较系统的阐述了单体、分布式系统、不可变基础设施下系统开发的理论知识，希望国内能有更多的前辈指引前路，再次表达感激
书籍网址：https://icyfenix.cn/ ，下载地址：https://raw.githubusercontent.com/fenixsoft/awesome-fenix/gh-pages/pdf/the-fenix-project.pdf
下面整理的知识点，还会不定时更新
1.浏览器预先获取DNS，加快多域名网站内容提前dns解析
<meta http-equiv="x-dns-prefetch-control" content="on" /><link rel="dns-prefetch" href="http://eiv.baidu.com">
2.CDN
Nginx对静态文件做CDN资源服务器
3.缓存
- 3.1.读数据时，先读缓存，缓存没有的话，再读数据源，然后将数据放入缓存，再响应请求。
- 3.2.写数据时，先写数据源，然后失效（而不是更新）掉缓存。
4.软件架构安全
-
认证（Authentication）：系统如何正确分辨出操作用户的真实身份？ -> 登录 , 前后端统一加解密
-
授权（ Authorization）：系统如何控制一个用户该看到哪些数据、能操作哪些功能？ -> RBAC
-
凭证（Credentials）：系统如何保证它与用户之间的承诺是双方当时真实意图的体现，是准确、完整且不可抵赖的？ -> JWT + HTTPS
-
保密（Confidentiality）：系统如何保证敏感数据无法被包括系统管理员在内的内外部人员所窃取、滥用？
client_hash = MD5(MD5(password) + salt) // SALT = $2a 10 10 10o5L.dWYEjZjaejOmN3x4Qu
client_hash = BCrypt(MD5(password) + salt) // MFfTW3uNI4eqhwDkG7HP9p2mzEUu/r2 -
传输（Transport Security）：系统如何保证通过网络传输的信息无法被第三方窃听、篡改和冒充？ HTTPS
-
验证（Verification）：系统如何确保提交到每项服务中的数据是合乎规则的，不会对系统稳定性、数据一致性、正确性产生风险？
所有的访问控制模型，实质上都是在解决同一个问题：谁（User）拥有什么权限（Authority）去操作（Operation）哪些资源（Resource） ，Spring Security
5.数据校验
- 1.Java Bean Validation简单规则校验，如：@NotBlank、@NotNull、@Email、@Size
- 2.自定义注解，实现复杂业务规则校验，@AuthenticatedAccount @NotConflictAccount
@POST
public Response updateUser(@Valid @AuthenticatedAccount @NotConflictAccount Account user) {
return CommonResponse.op(() -> service.updateAccount(user));
}
6.服务容错
7.熔断-限流：漏桶与令牌桶算法，多用令牌桶
8.安全性：Spring Security做安全控制
https://www.springcloud.cc/spring-security.html
9.可观测性：日志收集、链路追踪和聚合度量。logging、traceId、metrics
事件日志的职责是记录离散事件，通过这些记录事后分析出程序的行为；
追踪的主要目的是排查故障，比如分析调用链的哪一部分、哪个方法出现错误或阻塞，输入输出是否符合预期；
度量是指对系统中某一类信息的统计聚合，主要目的是监控和预警，当某些度量指标达到风险阈值时就触发事件，以便自动处理或者提醒管理员介入。
- 9.1.日志收集 ELK，其中Logstash可能被Fluentd取代，ELK 可以通过 Metricbeat 来实现度量的功能，由Spring Cloud Sleuth生成唯一TraceID
- 9.2.度量 Prometheus，作用是监控和告警alert，目的是揭示系统的总体运行状态，收集一些异常信息，达到多少就报警，，或者收集磁盘使用率达到90%就报警，需解决反复告警问题（如：触发某项告警后，马上重复多次告警发送邮件、短信）
- 9.3.追踪 Jaeger、skywalking、zipkin
Apache SkyWalking 的探针就可以同时支持度量和追踪两方面的数据来源，由OpenTracing进化而来OpenTelemetry，更是融合了日志、追踪、度量三者所长，有望成为三者兼备的统一可观测性的解决方案，https://opentelemetry.io/docs/
10.Kubernetes
-
1.网络：container veth0 -> veth1 -> linux bridge -> eth0
- 1.1. veth0和veth1是成对出现的虚拟以太网Virtual Ethernet ，优点是直接传输，无性能损耗
- 1.2. linux bridge是安装docker后自动安装的网桥，有ip地址、mac地址（device、dirver）
- 1.3. eth0 是硬件网卡
-
2.存储： Static Provisioning（静态分配）、Dynamic Provisioning（动态分配）
-
2.1.EmptyDir：本地存储，Pod内容器共享，Pod销毁时，本地存储数据被自动删除
-
2.2.PersistentVolume：持久化存储，一般是网络存储（NFS、ClusterFS、AWS-EBS），小团队开发测试NFS，生产ClusterFS
-
2.2.1.PersistentVolume由运维人员管理好存储
-
2.2.2.PersistentVolumeClaim由开发人员定义，声明需要的存储申请
-
2.2.3.由K8s匹配PersistentVolumeClaim与PersistentVolume，一旦匹配上，PersistentVolume就不能被别的Claim使用，如果匹配不上则Pod启动失败，
需要运维人员预先手动分配好若干个PersistentVolume，且会造成空间浪费，适应中小型团队 -
2.3.Local PersistentVolume：本地持久化存储，性能高，解决网络存储性能损失问题，但是k8s会把Pod调度到有该本地存储的Node上
-
2.4.Dynamic Provisioning：运维管理员准备好StorageClass，Provisioner，不再手工分配PersistentVolume，开发人员通过PersistentVolumeClaim声明所需的存储，明确指定由那个StorageClass，
如果StorageClass和Provisioner均可用，则StorageClass会按PersistentVolumeClaim的声明自动产生满足该要求的PersistentVolume，并发送给Provisioner，再把PersistentVolume给Pod使用
-
单体项目结构
- Resource对应 DDD 中的 User Interface 层，负责向用户显示信息或者解释用户发出的命令。可以是用户、另一个进程或计算机的服务。
- Application对应 DDD 中的 Application 层，负责定义软件本身对外暴露的能力，即软件本身可以完成哪些任务，并负责对内协调领域对象来解决问题。
根据 DDD 的原则，应用层要尽量简单，不包含任何业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使它们互相协作，
这一点在代码上表现为 Application 层中，一般不会存在任何的条件判断语句。实际上在许多项目中，Application 层都会被选为包裹事务
（代码进入此层事务开始，退出此层事务提交或者回滚）的载体。3.Domain对应 DDD 中的 Domain 层，负责实现业务逻辑，即表达业务概念，
处理业务状态信息以及业务规则这些行为，此层是整个项目的重点。 - Infrastructure对应 DDD 中的 Infrastructure 层，向其他层提供通用的技术能力，比如持久化能力、远程服务通讯、工具集，等等。
原书网址：https://icyfenix.cn/
