知识体系梳理
梳理技术体系
fus951
这个作者很懒,什么都没留下…
展开
-
软件开发的核心原则
将系统分解成独立的功能模块,降低系统的复杂度并提高可维护性。封装是隐藏对象的具体实现细节,仅暴露必要的接口供外部调用。避免冗余,确保信息在代码中的唯一性,减少错误和维护成本。接口隔离(使用多个专门的接口,而不是一个通用的大接口)还未出现的功能,不需要过早优化或添加不需要的功能。模块之间的接口应该是清晰定义,便于开发和测试。开放封闭(软件实体对扩展开放,对修改关闭)单一职责(一个类应该只有一个改变的原因)依赖倒置(依赖于抽象,不依赖于具体实现)设计应该尽可能简单,避免不必要的复杂性。原创 2024-09-18 20:47:14 · 156 阅读 · 0 评论 -
服务治理框架
对于外部Api调用或者客户端对后端API的访问,可以使用Http协议或者Restful(当然也可以直接通过最原始的socket来调用)。版本管理、负载均衡、流量控制、服务降级、资源隔离。当系统服务逐渐增多时,rpc调用链路将会越来越复杂。(消费组、提供者)服务注册、管理。需要大量文档维护工作来记录服务调用关系。需要一个对这些服务进行管理的框架。ESB(企业服务总线)原创 2024-09-18 20:22:23 · 87 阅读 · 0 评论 -
统一配置中心
将配置写在propeties、yaml、hcon等文件,是一种比较通用的方式。修改时,只需要更新配置文件重新部署,可以做到不牵扯代码层面的。方案:nacos、disconf、Apollo配置中心。在java中可以通过注解、XML配置方式引入相关配置。能够在线动态修改配置文件并生效。配置文件可以区分环境。原创 2024-09-18 20:00:15 · 82 阅读 · 0 评论 -
统一日志服务
统一日志服务则使用单独的日志服务器记录日志,各个业务通过统一的日志框架将日志输出到日志服务器上。将日志分散在各个业务中非常不方便对问题的管理和排查。原创 2024-09-18 20:28:14 · 103 阅读 · 0 评论 -
统一调度中心
很多业务中,定时调度都是一个非常普遍的场景:定时抓取数据、定时刷新订单状态。xxl-job、elastic-job等。任务执行的日志记录、故障报警。动态修改、停止、删除任务。cron表达式调度任务。统一调度中心:对所有调度任务进行管理。原创 2024-09-18 20:26:05 · 83 阅读 · 0 评论 -
单点登录系统
CAS验证凭证是否有效,如果有效,则创建一个票据(ticket)并将含有。,应用程序与CAS服务器通信验证凭证。通俗点将,只需要用户登录一次,客户端访问请求(已经拥有凭证),请求URL携带凭证信息,访问应用程序。客户端访问请求,因为未登录,所以重定向CAS服务器,用户输入凭证。票据的URL发送回给应用程序,应用程序通过与CAS服务器通信来验证。目前比较成熟的、用的比较多的单点登录系统应该是:CAS。(这过程中,若用户输入的凭证有误,将不会走后续流程)凭据的有效性,如果有效则运行访问资源。原创 2024-09-18 19:47:08 · 306 阅读 · 0 评论 -
后端技术导言
方案:去掉API网关的认证功能,直接对接统一认证中心,这里采用缓存认证结果的方式,避免对统一认证中心产生过大的请求压力。一个业务应用需要哪些技术、依赖哪些基础设施 --->决定了需要掌握的后端技术?App的管理:App的secret的生成、App信息的验证(验证接口签名)。通过统一认证中心构建移动APP的单点登录也是简单的事情:模仿web。监控:ELK日志分析平台、故障监控、全链路监控系统、系统监控。可用率、稳定性、容错性、扩展性、可维护性、安全性。缓存、数据库、搜索引擎、消息队列。原创 2024-09-18 18:53:13 · 210 阅读 · 0 评论