前言
架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序
- 搭一个草房子很简单，可以直接上手
- 盖一个2层楼房，稍微复杂，但在工匠经验指导下，问题也不大
- 盖一座高楼，复杂性就大不一样了，需要考虑内部结构、承重、采光、排水、防雷抗震等，需要专业人员事先做好整体的架构设计，并严格地按照设计施工
熵增定律：系统都是从有序到无序
熵是一种表示其系统中纷杂或者无序的量，放在软件系统演化也适用，系统里不停地添加业务功能，如果事先不做良好的设计，随着时间的推进，整个系统野蛮生长，就会逐渐碎片化，越来越无序，最终被推倒重来。
自然界中的生物可以通过和外界交互，主动进行新陈代谢，制造“负熵”，也就是降低混乱程度，来保证自身的有序性，继续生存
例如，植物通过光合作用，把光能、二氧化碳和水合成有机物，以此滋养自己，延续生命。
对于软件系统，我们也可以主动地调整系统各个部分的关系，保证系统整体的有序性，来更好地适用不断增长的业务和技术变化。
天下大势：分久必合，合久必分
架构实现从无序到有序，基本手段就是“分”与“合”
- 分。把系统拆分为各种子系统、模块、组件
三室一厅而不是大开间、两菜一汤而不是三下锅
- 合。基于业务流程和技术手段，把各个组件有机整合在一起。
屋子和书房原先用一堵墙分开，但是看书需求太强烈，直接把墙拿了，合成一个
好的架构应该有如下特点
- 满足业务的可扩展、可复用
- 满足系统的高可用、高性能
- 能用较低的成本落地
系统的组成
接入系统
- DNS
- Loader Balancer
- Web服务器
应用系统
- 开发框架
- 应用代码
- 三方库
核心组件
- Database
- 微服务框架
- 缓存
- 消息系统
- 搜索系统
- 流程引擎
- 大数据/NoSQL
支撑系统
- 日志系统
- 配置管理
- 任务调度
- 监控系统
- 安全风控
- 自动部署
- 资源管理
基础平台
- 语言进行时
- 容器/虚拟机
- 操作系统
- 硬件和网络
架构分类
业务架构
讲清楚核心业务的处理过程，定义各个业务模块的相互关系，从概念层面帮助我们理解系统面临哪些问题以及如何处理
电影的故事情节和场景安排
应用架构
讲清楚系统内部是怎么组织的，有哪些应用，相互间怎么调用的，它从逻辑层面帮助我们理解系统内部是如何分工与协作的
电影里有定义有哪些角色，每个角色有哪些职责，在每个场景中，这些角色是如何互动的。
技术架构
讲清楚系统由哪些硬件、操作系统和中间件组成，如果和我们开发应用一起配合，应用各种异常情况，保持系统的稳定可能
角色应该由谁来演，物理场景怎么布置，以此保证拍摄能顺利进行
总之：
- 做架构设计时，一般先考虑业务架构，再应用架构，最后技术架构。
- 开发的难点主要由业务架构和应用架构来解决，机器的痛点由技术架构来解决
- 另外，架构还需要考虑数据的可用性和一致性问题，这个可以参考CAP理论
CAP理论，系统的可用性、一致性和网络容错性，三个最多只能保证两个，在分布式系统的情况下，我们只能在C和A中选一个
复用的分类
技术复用
工具层面的复用
代码复用
- 函数
- 类库
- SDK
组件复用
- Redis
- MQ
- 框架
- 中间件
业务复用
业务实体复用
对各个业务领域的数据和业务规则进行封装，将它变成上层应用系统可以直接使用的业务组件
- 订单
- 商品
- 用户
- 会员
业务流程复用
把多个业务实体串起来，完成一个端到端的任务。
比如说，下单流程需要访问会员、商品、订单、库存等多个业务，如果我们把这些调用逻辑封装为一个下单流程服务，那下单页面就可以调用这个流程服务来完成下单，而不需要去深入了解下单的具体过程
- 下单流程
- 购物流程
产品复用
- 商城
- CRM
- ERP
- Sass系统
- Pass平台