由一次域名问题引发的探索(乱七八糟的东西)

本文探讨了内网域名是否需要在公网备案的问题,指出由于内网与公网的隔离,内网域名无需备案。同时,介绍了域名的作用、访问流程以及中国的域名实名制政策。内网可以通过自定义DNS实现域名映射,且备案主要是针对提供互联网信息服务的。文章还提及了NAS和DDNS等概念,并对备案的相关规定进行了简要分析。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

由一次域名问题引发的探索

缘起

  • 公司项目的测试环境和生产环境等环境都是部署在一个私有云中的,是一个内部的项目,用户是公司内部员工,访问方式为通过内网域名去访问,但app端是通过外网去访问的,这就引起了我的好奇心
  • 起先的问题很简单,通过域名去访问是不是需要注册域名(奇怪的问题)

学到的知识点

域名

  • 用自己的话来讲,在互联网中,每个主机都有一个ip,我们访问主机一般通过ip去访问,但是数字不友好,而且难记,如果通过ip访问的话,我想没有会想用一个数字ip来访问csdn什么的,所以出现了域名
  • 访问的大概流程是这样字:通过域名发起访问请求(比如通过浏览器),再通过dns映射到相应的ip,这其中涉及到网络的很多知识点,奈何基础太烂,所以暂时不细究了
    域名(百度baike-科普中国)

在内网中的域名是否需要在公网中备案?

域名实名制的一些东西

  • 一直不认证就暂停解析,个人理解毕竟DNS服务是国家开的,这个也算是基础设施之一吧,所以我理解国内一些小黄网、钓鱼网站总是可以找得到人的,关键是要让执法机构知道这个网站有问题,举报大法好啊。。。
    https://help.aliyun.com/document_detail/35881.html
    http://www.gov.cn/gongbao/content/2005/content_64290.htm

其他一些杂记

备案的一些东西

根据这两个东西,发现是提供我们这种互联网信息服务就需要备案,这个界定就不知道谁进行界定了,根据找到的资料貌似有啥80端口、443端口、8080端口肯定是需要的,从腾讯云和阿里云的规定来看,貌似这个和端口也没关系,说是会扫描(那我们在非云上的东西是不是也是可能会被扫描到呢?),就只跟你是否使用此域名提供互联网信息服务,感觉唯一可以界定的就是是不是在中国大陆了
是否需要备案-腾讯云doc

nas

听过nas并不需要备案,貌似只是需要一个域名,还有一个DDNS(主要貌似是自己电脑每次都会变,这样就可以没那么麻烦,每次找IP),可能并不能算是严格意义上的互联网信息服务

碎碎念,markdown用不习惯。。。基本上全是猜的感觉,然后的话感觉权威性也不强,先这样吧的😂,都没写过这种东西,给点鼓励
<think>好的,用户之前让我解释微服务并画个图,但用户现在反馈说图对齐有问题,看起来乱七八糟。我需要先检查之前的回复,看看哪出了问题。 之前的架构示意图用了文本符号,可能在移动设备或不同字体下显示不一致,导致对齐错乱。用户可能是在手机上看,或者使用的字体不是等宽字体,所以原本设计的ASCII图形无法正确对齐。比如,箭头和连接线可能没有正确连接各个组件,导致结构不清晰。 用户的需求其实是想通过清晰的图表来理解微服务架构的结构,所以需要提供更可靠的图示方法。直接建议用户用专业的绘图工具可能更有效,比如推荐使用Draw.io或PPT,因为这些工具生成的图表不会受文本格式影响。另外,可以给出具体的绘制步骤,帮助用户自己创建结构正确的图,或者提供一个更简化的文本描述,尽量使用对齐的符号,比如使用减号和竖线来保持结构。 同时,用户可能对技术细节不太熟悉,所以需要避免使用复杂的术语,用更易懂的语言解释每个部分的作用,比如API网关负责请求路由,服务发现帮助定位服务实例等。还需要补充微服务的关键组件,如配置中心、监控系统,这些在之前的回复中没有提到,但能帮助用户更全面理解架构。 另外,考虑到用户可能没有绘图工具,提供一个基于文本的简化版架构图,使用等宽字体和简单符号,尽可能保持对齐。同时,说明如果显示有问题,建议换用其他工具,这样用户可以根据自己的情况选择合适的方式查看。 最后,总结微服务的优缺点,并给出实际应用中的建议,帮助用户理解何时选择微服务架构。确保回复结构清晰,分点明确,让用户一步步理解问题所在以及解决方案。</think>您观察得很仔细!纯文本绘制架构图确实容易出现对齐问题。我重新整理一个更清晰的版本,并附上绘制建议: --- ### **修正后的微服务架构图(文本简化版)** ``` 客户端 │ ▼ API网关 │ ├───────────┐ ▼ ▼ 用户服务 订单服务 支付服务 │ │ │ ▼ ▼ ▼ 用户数据库 订单数据库 支付数据库 ``` --- ### **推荐绘图方式(非文本实现)** 1. **使用专业工具绘制**(如:Draw.io/PPT/Excalidraw) - **核心组件**: ``` [客户端] → [API网关] → [服务发现] ↙ ↓ ↘ [服务A] [服务B] [服务C] | | | [DB1] [DB2] [DB3] ``` 2. **关键对齐规则**: - **垂直对齐**:服务层级(如所有数据库在底层对齐) - **水平间距**:相同层级的服务间距一致 - **连接线方向**:统一使用直角箭头(避免交叉) --- ### **架构核心组件说明** 1. **API网关**:统一入口,处理路由、认证、限流 2. **服务发现**:动态管理服务实例地址(如Consul/Eureka) 3. **独立服务**: - 每个服务包含完整业务逻辑 + 独立数据库 - 通过HTTP/RPC互相调用(如订单服务调用支付服务) 4. **支撑系统**(图中未展示但实际必需): - 配置中心(如Nacos) - 监控系统(如Prometheus+Grafana) - 日志聚合(如ELK) --- ### **若文本显示仍错位** 建议访问在线绘图工具(如 [Draw.io](https://app.diagrams.net/))直接使用以下模板: ![微服务架构图](https://miro.medium.com/v2/resize:fit:1400/1*H_6Nb5XRUOeMGhvpCMyuLQ.png) (此处为示意图链接描述,实际需替换为可访问的图片地址) --- ### **关键总结** - **核心原则**:通过拆分实现高内聚、低耦合 - **适用场景**:需快速迭代的中大型系统(如电商平台) - **取舍平衡**:用运维复杂度换取开发灵活性和扩展性 如果需要更具体的实现示例,我可提供分步骤的架构搭建说明!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值