技术架构演化
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
最终目标：可维护/可扩展/高可用
客户端 + 服务端 + 数据层
服务端提供了所有的 API 接口：这个服务端是非常大的，非常大的服务是不可维护的（每次上线都需要整体上线/编译的速度很慢）
所以为了解决这个问题，需要引入微服务的概念。
在客户端和服务端之间增加一个接入层
接入层主要负责的内容有负载均衡/网关
服务端则需要根据业务来划分出来不同的微服务进行模块构成业务逻辑层来支撑业务
再往下是存储层，包括数据库（mysql/clickhouse/hbase/mongodb/abase/etcd）,缓存（redis），包括异步离线使用的队列（kafka/nsq），文件系统（HDFS）
再往下是基础设施的构建，包括 Iaas，Paas 以及最底层的 IDC(Internet Data Center)
这个架构能够在中小公司中适用，但是整个架构的扩展性还不够好
*
以上的架构能够支撑单个 APP，但是如果公司中需要对多个 APP 进行支撑，那么简单的处理方式是将业务逻辑层复制一份，然后在此基础上进行修改。
为了良好的扩展性，这个问题可以通过共享库/服务/平台进行处理。
共享库是代码级别，将可复用的代码抽离成一个组件/代码库，供其他业务进行使用。
服务是 SDK 级别，将某一业务（例如用户信息）封装为一个服务，可以提供给各个代码库进行接入使用。
平台是在提供通用服务的同时，还提供可管理/可配置/可视化的平台，业务方可以个性化配置，可视化观察。
这样，业务逻辑层还是存在的，不过其中的通用代码和服务抽离出来在下层构成一层共享服务和平台。
解决业务团队重复造轮子
中后台成熟后，前台业务更加敏捷
技术层面广度（业务场景）和深度都可以做得更好
这样整个服务架构在扩展性上做的更好，但是在稳定性上还欠缺更多的盘路能力，比如更好的服务治理能力，线下测试环境以及降级/容灾能力
服务之间的上线部署/流量控制/发生事故时快速切断有问题的服务
联调隔离线上环境（防止脏数据/代码 bug）
缓存穿透
服务降级
存储/流量的切换
*