Java 知识点学习 第一天
每天学一点 java 知识, 让菜鸟慢慢飞
鉴于 Java 基础薄弱, 现每天会花一些时间, 补充知识.
架构相关
如何选择 单体架构与微服务
单体架构
适用场景
- 小项目, 产品初期, 人员投入较少
- 想快速迭代, 验证产品想法
缺点
- IDE过载: 编译效率下降. 代码量大了, 所有文件编译时间会被拉长
- 规模化问题: 无法满足规模化高效开发, 团队大了 ,会造成冲突几率增加, 没有隔离变化,导致出了问题,影响面变大.
- 开发,测试,部署的冲突和效率低下等问题
- 只能关注一套技术栈
- 应用扩展性比较差, 臃肿, 耦合性太高
- 海量用户高并发访问数量有限, 没有分布式,负载
总结
架构是不断演化的, 对于初始的单体架构,也可以慢慢改造. 当然最好是面向微服务设计单体架构.
单体架构要注意分层, 无论采取何种维度的架构分层，分层的最核心目的是保证各层之间的差异足够清晰，边界足够明显，为将来可能产生的变化提供最容易 !!!
微服务
优点
- 对团队协同友好
- 能负担庞大业务,适应快速业务增长
- 支撑海量用户高并发和海量设备接入
- 支持分布式多机房, 多区域部署
- 支持服务器无限扩容
- 支持私有云，公有云，混合云等部署方式
缺点
- 技术门槛高, 这么多优点,是需要极高的技术支撑
- 复杂性增加, 如何拆分系统是难点, 服务监控, 追踪, 治理 难度增大
- 投入 人力, 财力, 等成本巨大
微服务架构图
微服务最大的难点在于服务的划分和粒度控制，另外如何管理膨胀的服务是一个麻烦事. 如何这做不好, 还会反受其累!
ps: 一个好的iOS组件化,关键是提供一套好的路由和事件总线机制
落地微服务的评估
对于技术人员,管理人员来讲, 不要盲目跟风. 使用微服务的前提是 要有一定的技术团队支撑.
- 落地方式, 一种是外部引入, 一种是内部自行研究
- 人才储备
- 技术储备
- 团队规模
整个细节今天就不摘录了, 链接如下, 后面还需反复学习.
架构设计三原则：
- 合适原则
- 简单原则
- 演化原则
SOLID 面向对象设计原则
*. 单一职责原则 (The Single Responsibility Principle)
* 修改某个类的理由应该只有一个，如果超过一个，说明类承担不止一个职责，要视情况拆分。
- 开放封闭原则 (The Open Closed Principle)
- 软件实体应该对扩展开放，对修改封闭。一般不要直接修改类库源码（即使你有源代码），通过继承等方式扩展。
- 里氏替代原则 (The Liskov Substitution Principle)
- 当一个子类的实例能够被替换成任何超类的实例时，它们之间才是真正的 is-a 关系。
- 依赖倒置原则 (The Dependency Inversion Principle)
- 高层模块不应该依赖于底层模块，二者都应该依赖于抽象。换句话说，依赖于抽象，不要依赖于具体实现
- 协议化
- 接口分离原则 (The Interface Segregation Principle)
- 不要强迫用户去依赖它们不使用的接口。换句话说，使用多个专门的接口比使用单一的大而全接口要好。
GRASP 通用职责分配软件模式
- 信息专家 (Information Expert)
- 为对象分配职责的通用原则 – 把职责分配给拥有足够信息可以履行职责的专家
- 创建者 (Creator)
- 将创建 A 的职责赋给 B，如果至少下面一种情况为真：
- B“包含”或者聚合 A
- B 记录 A 的实例
- B 密切地使用 A
- B 拥有 A 的初始化数据
- 将创建 A 的职责赋给 B，如果至少下面一种情况为真：
- 低耦合 (Low Coupling)
- 赋予职责使得对象间的耦合度尽可能低，最小化对象间的依赖和变更影响，最大化重用。
- 高内聚 (High Cohesion)
- 赋予职责使得每个对象的职责尽可能保持聚焦和单一，易于管理和理解
- 控制器 (Controller)
- 把职责赋予系统、设备或者子系统的表示类 (门面控制器)，或者某个用例的表示类 (用例控制器)，让控制器接收事件并协调整个系统的运作。
- 多态 (Polymorphism)
- 将职责分配给多个具有同名方法的多态子类，运行时根据需要动态切换子类，让系统行为变得可插拔。
- 访问者模式
- 纯虚构 (Pure Fabrication)
- 针对真实问题域中不存在，但是设计建模中有用的概念，设计虚构类并赋予职责。
- 间接 (Indirection)
- 在两个或者多个对象间有交互的情况下，为避免直接耦合，提高重用性，创建中间类并赋予职责，对象的交互交由中间类协调。
- 中介者模式, 比如iOS 的 CTMediator 组件化, 比如 Spring 容器
- 受保护的变化 (Protected Variation)
- 简单讲就是封装变化。识别系统中可能的不稳定或者变化，在不稳定组件上创建稳定的抽象接口，将可能的变化封装在接口之后，使得系统内部的不稳定或者变化不会对系统的其它部分产生不良影响。
总结性语言
- 高内聚 + 低耦合 属于 元原则, 也就是说, 很多OO原则是建立在这个基础之上或者衍化来的
分布式系统架构设计原则和理论
AKF 架构原则
- N + 1 设计
- 永远不要少于两个，通常为三个。比方说无状态的 Web/API 一般部署至少>=2 个。
- 回滚设计
- 确保系统可以回滚到以前发布过的任何版本。可以通过发布系统保留历史版本，或者代码中引入动态开关切换机制 (Feature Switch)
- 禁用设计
- 能够关闭任何发布的功能。新功能隐藏在动态开关机制 (Feature Switch) 后面，可以按需一键打开，如发现问题随时关闭禁用
- 监控设计
- 在设计阶段就必须考虑监控，而不是在实施完毕之后补充。例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发 (Metrics Driven Development) 的理念。
- 设计多活数据中心
- 不要被一个数据中心的解决方案把自己限制住。当然也要考虑成本和公司规模发展阶段
- 使用成熟的技术
- 只用确实好用的技术。商业组织毕竟不是研究机构，技术要落地实用，成熟的技术一般坑都被踩平了，新技术在完全成熟前一般需要踩坑躺坑。
- 异步设计
- 能异步尽量用异步，只有当绝对必要或者无法异步时，才使用同步调用
- 无状态系统
- 尽可能无状态，只有当业务确实需要，才使用状态。无状态系统易于扩展，有状态系统不易扩展且状态复杂时更易出错。
- 水平扩展而非垂直升级
- 永远不要依赖更大、更快的系统。一般公司成长到一定阶段普遍经历过买更大、更快系统的阶段，即使淘宝当年也买小型机扛流量，后来扛不住才体会这样做不 scalable，所以才有后来的去 IOE 行动。
- 设计时至少要有两步前瞻性
- 在扩展性问题发生前考虑好下一步的行动计划。架构师的价值就体现在这里，架构设计对于流量的增长要有提前量
- 非核心则购买
- 如果不是你最擅长，也提供不了差异化的竞争优势则直接购买。避免 Not Invented Here 症状，避免凡事都要重造轮子，毕竟达成业务目标才是重点。
- 使用商品化硬件
- 在大多数情况下，便宜的就是最好的。这点和第 9 点是一致的，通过商品化硬件水平扩展，而不是买更大、更快的系统。
- 小构建、小发布和快试错
- 全部研发要小构建，不断迭代，让系统不断成长。这个和微服务理念一致。
- 隔离故障
- 实现故障隔离设计，通过断路保护避免故障传播和交叉影响。通过舱壁泳道等机制隔离失败单元 (Failure Unit)，一个单元的失败不至影响其它单元的正常工作。
- 自动化
- 设计和构建自动化的过程。如果机器可以做，就不要依赖于人。自动化是 DevOps 的基础。
CAP 定理 用于分布式系统
- 一致性 (Consistency)
- 一致性指“all nodes see the same data at the same time”，即更新操作成功，所有节点在同一时间的数据完全一致
- 可用性 (Availability)
- 可用性指“Reads and writes always succeed”，即服务一直可用，而且响应时间正常。
- 分区容忍性 (Partition tolerance)
- 分区容忍性指“the system continue to operate despite arbitrary message loss or failure of part of the system.”，即分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性和可用性的服务。
总结 三者不可得兼, 一般只能满足其二
BASE 理论 - 在 CAP 基础上的延伸
核心思想是即使无法做到强一致性 (Strong Consistency，CAP 中的一致性指强一致性)，但是可以采用适当的方式达到最终一致性 (Eventual Consistency)。
- 基本可用 (Basically Available)
- 基本可用是指分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。比如服务降级。
- 软状态 (Soft State)
- 软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少存三个副本，允许不同节点间副本同步的延迟就是软状态的体现
- 最终一致性 (Eventual Consistency)
- 最终一致性是指系统中的所有数据副本经过一段时间后，最终能够达成一致状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
使用某个产品的时候,要明白其实如何保证CAP的, 从哪个点切入