[{"data":1,"prerenderedAt":1981},["ShallowReactive",2],{"blog-\u002Fblog\u002Fcomparison\u002Frenlian-shibie-hegui":3,"blog-related-\u002Fblog\u002Fcomparison\u002Frenlian-shibie-hegui":395},{"id":4,"title":5,"author":6,"body":7,"category":365,"cover":366,"date":367,"description":368,"draft":369,"extension":370,"faq":371,"featured":369,"image":366,"keywords":381,"meta":385,"navigation":386,"path":387,"seo":388,"sitemap":389,"stem":390,"tags":391,"updated":367,"__hash__":394},"blog\u002Fblog\u002Fcomparison\u002Frenlian-shibie-hegui.md","人脸识别的合规边界","HNREIS",{"type":8,"value":9,"toc":347},"minimark",[10,19,22,26,37,47,50,53,58,64,74,78,84,90,94,100,110,114,120,126,130,140,143,193,198,209,212,234,237,258,261,311,314,317,338,341],[11,12,13,14,18],"p",{},"人脸识别用生物信息，",[15,16,17],"strong",{},"高度敏感，合规要求严。"," 这篇讲清边界和企业怎么合规用。",[11,20,21],{},"人脸识别这几年应用爆发——门禁、支付、考勤、安防、营销随处可见。但同时监管也在收紧——\"售楼处用人脸识别判客被罚\"\"APP 强制人脸登录被通报\"\"小区人脸门禁引争议\"这类新闻屡见不鲜。人脸不是普通数据，它是不可更改的生物特征，一旦泄露影响终身。所以法规对人脸识别的监管比对普通个人信息更严。企业想用人脸识别，必须先搞清楚合规边界在哪。这篇讲清楚。",[23,24,25],"h2",{"id":25},"人脸识别的特点",[11,27,28,29,32,33,36],{},"人脸识别的特殊性在于：",[15,30,31],{},"生物信息","——人脸是不可更改的生物特征，和密码、手机号这种\"可以换\"的信息本质不同。",[15,34,35],{},"高度敏感","——根据《个人信息保护法》，人脸信息属于敏感个人信息，处理规则更严格（要取得单独同意、要有特定目的和充分必要性）。",[11,38,39,42,43,46],{},[15,40,41],{},"泄露后果严重","——密码泄露了可以改，人脸泄露了没法换。一旦人脸数据被非法获取，可能被用于伪造身份、绕过其他系统的活体检测，影响是终身的。",[15,44,45],{},"强监管","——除 PIPL 外，《网络安全法》《数据安全法》《最高人民法院关于审理使用人脸识别技术处理个人信息相关民事案件适用法律若干问题的规定》都对人脸识别有严格规定。",[11,48,49],{},"人脸和密码的本质区别在于：密码泄露了可以改，人脸泄露了没法换。一旦人脸数据被非法获取，影响是终身的。这就是为什么法规对人脸识别的监管比对普通个人信息更严。",[23,51,52],{"id":52},"合规要求",[54,55,57],"h3",{"id":56},"_1-告知同意","1. 告知同意",[11,59,60,63],{},[15,61,62],{},"明确告知采集人脸","——要让用户清楚知道在采集人脸数据、用于什么目的、保存多久、会不会共享给第三方。告知要清晰、具体、可理解，不能藏在冗长隐私政策的角落里。",[11,65,66,69,70,73],{},[15,67,68],{},"取得用户同意","——而且要\"单独同意\"，不能和其他授权捆绑（不能\"同意服务条款就等于同意人脸采集\"）。",[15,71,72],{},"不能偷偷采集","——这是红线。无告知无同意的人脸采集是严重违规，近年来多起案件都是这个原因被罚。",[54,75,77],{"id":76},"_2-最小必要","2. 最小必要",[11,79,80,83],{},[15,81,82],{},"有替代方案时不用人脸","——如果门禁可以用刷卡、扫码、密码等方式实现，就不应该强制用人脸。只有当人脸识别是\"必要\"的（没有合理替代方案，或者替代方案成本明显过高）时才考虑使用。",[11,85,86,89],{},[15,87,88],{},"只在必要场景用","——判断标准是\"不用人脸，业务能不能正常开展\"。能正常开展就不该用人脸。比如普通门禁完全可以用刷卡，没必要上人脸；但金融级身份核验可能需要人脸（活体检测防冒用）。",[54,91,93],{"id":92},"_3-安全保护","3. 安全保护",[11,95,96,99],{},[15,97,98],{},"加密存储","——人脸特征数据要加密存储，不能明文保存。传输过程也要加密（TLS）。建议存特征向量而非原始图像，降低泄露影响。",[11,101,102,105,106,109],{},[15,103,104],{},"权限管控","——谁有权访问人脸数据要严格控制，最小权限原则。运维、客服、业务人员不该有访问权限。",[15,107,108],{},"防泄露","——技术防护（加密、权限、审计）+ 管理防护（制度、培训、审计），双管齐下。建立数据泄露应急预案。",[54,111,113],{"id":112},"_4-目的合法","4. 目的合法",[11,115,116,119],{},[15,117,118],{},"按告知目的用","——采集时说用于门禁，就只能用于门禁，不能偷偷拿去做营销分析、客流统计、画像。目的变更要重新告知同意。",[11,121,122,125],{},[15,123,124],{},"不超范围","——超范围使用是常见违规点。比如某商场以\"安防\"名义装人脸识别，实际用于分析客户画像和精准营销，这就是超范围使用。",[54,127,129],{"id":128},"_5-提供替代","5. 提供替代",[11,131,132,135,136,139],{},[15,133,134],{},"不愿用的人脸识别要有替代方式","——这是合规的关键。即使你用人脸识别，也要提供替代方案（如刷卡、扫码、密码），让不愿被人脸识别的用户有选择。",[15,137,138],{},"不强制","——强制人脸识别（没有替代方案）是高风险违规。最高法司法解释明确，强制人脸识别属于侵害人格权益的行为。",[23,141,142],{"id":142},"风险高的场景",[144,145,146,159],"table",{},[147,148,149],"thead",{},[150,151,152,156],"tr",{},[153,154,155],"th",{},"场景",[153,157,158],{},"风险",[160,161,162,171,179,186],"tbody",{},[150,163,164,168],{},[165,166,167],"td",{},"公共场所无感采集",[165,169,170],{},"高（未同意）",[150,172,173,176],{},[165,174,175],{},"强制（无替代）",[165,177,178],{},"高",[150,180,181,184],{},[165,182,183],{},"超范围使用",[165,185,178],{},[150,187,188,191],{},[165,189,190],{},"数据不安全",[165,192,178],{},[11,194,195,197],{},[15,196,167],{},"是风险最高的场景——商场、售楼处、小区在用户不知情的情况下采集人脸，没有告知也没有同意，严重违规。近年来多起案例（如售楼处判客、小区门禁）都被监管处罚或民事诉讼。",[11,199,200,202,203,205,206,208],{},[15,201,175],{},"——只提供人脸识别一种方式，用户没有选择权，违反\"自愿原则\"。",[15,204,183],{},"——以一个目的采集，用于另一个目的，违反目的限制。",[15,207,190],{},"——人脸数据明文存储、权限混乱、无审计，泄露风险高。",[23,210,211],{"id":211},"合规的场景",[213,214,215,222,228],"ul",{},[216,217,218,221],"li",{},[15,219,220],{},"门禁","：告知同意 + 有替代（如刷卡）。让用户自愿选择是否使用人脸门禁，不强制。",[216,223,224,227],{},[15,225,226],{},"支付","：告知同意 + 有替代（如密码）。支付场景下人脸是便捷选项，但必须有密码、指纹等替代方式。",[216,229,230,233],{},[15,231,232],{},"必要身份核验","：告知同意。如金融开户、政务服务的实名认证，这类场景人脸识别有合理性，但仍要告知同意、保护数据。",[23,235,236],{"id":236},"别踩的坑",[11,238,239,242,243,246,247,250,251,253,254,257],{},[15,240,241],{},"偷偷采集","——无告知无同意的人脸采集，严重违规。",[15,244,245],{},"强制无替代","——只提供人脸一种方式，违反自愿原则。",[15,248,249],{},"超范围用","——一个目的采集，另一个目的使用，违规。",[15,252,190],{},"——明文存储、权限混乱、无审计，泄露风险高。",[15,255,256],{},"能不用滥用","——人脸识别不是噱头，能不用就不用。每多一个使用场景就多一份合规风险和数据风险。",[23,259,260],{"id":260},"成本参考",[144,262,263,276],{},[147,264,265],{},[150,266,267,270,273],{},[153,268,269],{},"方面",[153,271,272],{},"说明",[153,274,275],{},"成本",[160,277,278,289,300],{},[150,279,280,283,286],{},[165,281,282],{},"人脸识别技术",[165,284,285],{},"云API\u002F开源",[165,287,288],{},"低到中",[150,290,291,294,297],{},[165,292,293],{},"合规设计",[165,295,296],{},"告知\u002F同意\u002F安全",[165,298,299],{},"含在开发",[150,301,302,305,308],{},[165,303,304],{},"法律咨询",[165,306,307],{},"复杂",[165,309,310],{},"中",[11,312,313],{},"人脸识别技术本身成本不高——云 API（如阿里云、腾讯云人脸识别）按调用计费，开源方案（如 OpenCV、InsightFace）免费但要技术团队部署。合规设计应该内建在开发过程，不另算大支出。法律咨询（复杂场景的合规评估）几千到几万。",[23,315,316],{"id":316},"怎么合规",[318,319,320,326,329,332,335],"ol",{},[216,321,322,325],{},[15,323,324],{},"能不用就不用","——这是首要原则。每多用一次人脸识别就多一份合规风险，能用其他方案就用其他方案。",[216,327,328],{},"必要用要告知同意——清晰的告知 + 单独同意，不捆绑、不偷偷。",[216,330,331],{},"提供替代方案——让人脸识别成为选项而非强制。",[216,333,334],{},"安全保护——加密存储、权限管控、审计日志、泄露预案。",[216,336,337],{},"目的限制——按告知目的使用，不超范围。",[11,339,340],{},"核心原则：人脸识别不是技术炫技，是涉及人格权益的敏感处理。能不用就不用，用了要严守合规。",[342,343,344],"blockquote",{},[11,345,346],{},"广州市汉诺雷斯（HNREIS）帮企业做人脸识别（含合规设计：告知\u002F同意\u002F安全\u002F替代），法律细节建议咨询专业。把你的需求告诉我们，我们给出方案。",{"title":348,"searchDepth":349,"depth":349,"links":350},"",2,[351,352,360,361,362,363,364],{"id":25,"depth":349,"text":25},{"id":52,"depth":349,"text":52,"children":353},[354,356,357,358,359],{"id":56,"depth":355,"text":57},3,{"id":76,"depth":355,"text":77},{"id":92,"depth":355,"text":93},{"id":112,"depth":355,"text":113},{"id":128,"depth":355,"text":129},{"id":142,"depth":349,"text":142},{"id":211,"depth":349,"text":211},{"id":236,"depth":349,"text":236},{"id":260,"depth":349,"text":260},{"id":316,"depth":349,"text":316},"comparison",null,"2025-05-25","人脸识别用生物信息，高度敏感，合规要求严。本文讲清人脸识别的合规边界、风险和企业怎么合规用。",false,"md",[372,375,378],{"q":373,"a":374},"人脸识别合规吗？","看场景和合规。人脸是生物识别信息，高度敏感，法规严格。要做：明确告知并取得同意、最小必要（有替代方案时不用人脸）、安全保护、目的合法。部分场景（如某些公共场所无感采集）受限或禁用。违规有处罚。",{"q":376,"a":377},"企业用人脸识别要注意什么？","几点：明确告知同意（不能偷偷采集）、最小必要（有替代方案优先）、安全保护（加密\u002F权限）、目的合法（不能超范围用）、提供替代方式（不愿用的有其他选择）。建议人脸识别能不用就不用，用了要严格合规。",{"q":379,"a":380},"哪些场景人脸识别合规风险高？","公共场所无感采集（未告知同意）、强制（无替代方案）、超范围使用（采集了用于别的目的）、数据不安全。这些风险高。建议人脸识别用于必要场景（如门禁\u002F支付，且告知同意+有替代），避免敏感场景滥用。",[382,383,31,384],"人脸识别","人脸合规","人脸识别风险",{},true,"\u002Fblog\u002Fcomparison\u002Frenlian-shibie-hegui",{"title":5,"description":368},{"loc":387},"blog\u002Fcomparison\u002Frenlian-shibie-hegui",[382,392,393],"合规","隐私","YHEnZFVMWjTKBMcP_K4wwpShMO5-FgWFAHFqHqWFqNQ",[396,800,1219,1586],{"id":397,"title":398,"author":6,"body":399,"category":365,"cover":366,"date":773,"description":774,"draft":369,"extension":370,"faq":775,"featured":369,"image":366,"keywords":785,"meta":790,"navigation":386,"path":791,"seo":792,"sitemap":793,"stem":794,"tags":795,"updated":773,"__hash__":799},"blog\u002Fblog\u002Fcomparison\u002Fapi-jiekou-shiye.md","API、接口、集成这些词到底是什么意思",{"type":8,"value":400,"toc":753},[401,407,411,417,420,431,436,439,442,448,451,456,458,469,474,477,480,494,497,511,516,519,523,537,540,551,554,559,562,569,586,591,594,597,619,624,627,664,670,673,699,702,705,731,734,748],[11,402,403,404],{},"老板常被 API、接口、集成这些技术词绕晕。",[15,405,406],{},"这篇用大白话讲清，帮老板听懂技术沟通。",[23,408,410],{"id":409},"api-是什么大白话","API 是什么（大白话）",[11,412,413,416],{},[15,414,415],{},"API 是两个软件\"对话\"的通道","。",[11,418,419],{},"例子：",[213,421,422,425,428],{},[216,423,424],{},"你的小程序要查物流 → 通过物流公司 API 问\"单号到哪了\" → 物流系统回\"已签收\"。",[216,426,427],{},"你的官网要收款 → 通过支付 API 让客户付款 → 支付系统回\"付款成功\"。",[216,429,430],{},"你的系统要发短信 → 通过短信 API 发 → 短信平台发出去。",[11,432,433,416],{},[15,434,435],{},"API 让不同软件自动互通数据，不用人工搬",[11,437,438],{},"打个比方：API 像餐厅的\"服务员\"——你（小程序）告诉服务员（API）要什么，服务员告诉厨房（另一个系统），厨房做好端回来。你不用自己进厨房。",[23,440,441],{"id":441},"接口是什么",[11,443,444,447],{},[15,445,446],{},"接口就是 API","（同义词）。技术人员说\"做个接口\"\"对接接口\"，就是做 API 让系统互通。",[23,449,450],{"id":450},"集成是什么",[11,452,453,416],{},[15,454,455],{},"集成 = 把多个系统通过 API 连起来，数据自动流通",[11,457,419],{},[213,459,460,463,466],{},[216,461,462],{},"独立站 + ERP 集成：独立站订单自动进 ERP，ERP 库存自动同步独立站。",[216,464,465],{},"小程序 + CRM 集成：小程序客户数据自动进 CRM。",[216,467,468],{},"系统 + 支付集成：系统通过支付 API 收款。",[11,470,471,416],{},[15,472,473],{},"集成让数据自动流，替代人工搬数据",[23,475,476],{"id":476},"企业为什么要做接口集成",[54,478,479],{"id":479},"不集成的问题",[213,481,482,485,488,491],{},[216,483,484],{},"多个系统（独立站\u002FERP\u002FCRM\u002F物流），数据不通。",[216,486,487],{},"人工把数据从一个系统搬到另一个（累、易错）。",[216,489,490],{},"数据不同步（独立站卖了 ERP 库存没减，超卖）。",[216,492,493],{},"效率低。",[54,495,496],{"id":496},"集成的好处",[213,498,499,502,505,508],{},[216,500,501],{},"数据自动流通（订单\u002F库存\u002F客户自动同步）。",[216,503,504],{},"替代人工（省人力、避错）。",[216,506,507],{},"实时同步（不超卖、不漏单）。",[216,509,510],{},"数据统一（可分析）。",[11,512,513,416],{},[15,514,515],{},"系统越多，集成价值越大",[23,517,518],{"id":518},"常见的集成场景",[54,520,522],{"id":521},"电商独立站","电商\u002F独立站",[213,524,525,528,531,534],{},[216,526,527],{},"独立站 ↔ ERP（订单\u002F库存同步）。",[216,529,530],{},"独立站 ↔ 物流（发货\u002F追踪）。",[216,532,533],{},"独立站 ↔ 支付（收款）。",[216,535,536],{},"独立站 ↔ CRM（客户管理）。",[54,538,539],{"id":539},"企业内部",[213,541,542,545,548],{},[216,543,544],{},"系统 ↔ OA（审批\u002F通知）。",[216,546,547],{},"系统 ↔ 财务（对账\u002F开票）。",[216,549,550],{},"系统 ↔ 企微\u002F钉钉（消息\u002F工作流）。",[54,552,553],{"id":553},"数据",[213,555,556],{},[216,557,558],{},"系统 ↔ 数据分析（数据汇总\u002F报表）。",[23,560,561],{"id":561},"集成怎么实现",[11,563,564,565,568],{},"通过 ",[15,566,567],{},"API 对接","：",[318,570,571,574,577,580,583],{},[216,572,573],{},"确认要对接的系统（ERP\u002F物流\u002F支付）。",[216,575,576],{},"看各系统是否提供 API（文档）。",[216,578,579],{},"开发对接（系统间调 API 传数据）。",[216,581,582],{},"测试（数据准确、异常处理）。",[216,584,585],{},"上线 + 监控。",[11,587,588,416],{},[15,589,590],{},"自建系统（Nuxt\u002FVue）能灵活对接任意系统，这是它比 SaaS 的优势",[23,592,593],{"id":593},"老板该懂什么",[11,595,596],{},"老板不用懂代码，懂这些：",[213,598,599,604,609,614],{},[216,600,601,416],{},[15,602,603],{},"API = 软件之间自动传数据的通道",[216,605,606,416],{},[15,607,608],{},"集成 = 多系统数据自动流通",[216,610,611,416],{},[15,612,613],{},"集成能替代人工、提效避错",[216,615,616,416],{},[15,617,618],{},"集成成本看系统数量和复杂度",[11,620,621,416],{},[15,622,623],{},"懂这些，就能和技术\u002F服务商沟通集成需求",[23,625,626],{"id":626},"集成的成本",[144,628,629,638],{},[147,630,631],{},[150,632,633,636],{},[153,634,635],{},"集成类型",[153,637,275],{},[160,639,640,648,656],{},[150,641,642,645],{},[165,643,644],{},"对接一个系统（如 ERP）",[165,646,647],{},"1-3 万",[150,649,650,653],{},[165,651,652],{},"多系统集成",[165,654,655],{},"3-8 万",[150,657,658,661],{},[165,659,660],{},"复杂（双向同步\u002F多系统\u002F定制）",[165,662,663],{},"8 万+",[11,665,666,669],{},[15,667,668],{},"ROI 明确","（替代人工、提效、避错）。",[23,671,672],{"id":672},"常见误区",[213,674,675,681,687,693],{},[216,676,677,680],{},[15,678,679],{},"\"接口很复杂不用懂\"","：老板懂概念就行（API = 数据通道）。",[216,682,683,686],{},[15,684,685],{},"\"不集成也能用\"","：人工搬数据累易错，不可持续。",[216,688,689,692],{},[15,690,691],{},"\"集成是一次性的\"","：系统升级\u002F业务变化，集成要维护。",[216,694,695,698],{},[15,696,697],{},"\"SaaS 不用集成\"","：SaaS 也要和其他系统打通。",[23,700,701],{"id":701},"怎么判断要不要集成",[11,703,704],{},"问自己：",[318,706,707,713,719,725],{},[216,708,709,712],{},[15,710,711],{},"有多个系统吗？"," 有 → 可能要集成。",[216,714,715,718],{},[15,716,717],{},"人工搬数据吗？"," 搬 → 该集成。",[216,720,721,724],{},[15,722,723],{},"数据需要同步吗？"," 需要 → 集成。",[216,726,727,730],{},[15,728,729],{},"集成 ROI 划算吗？","（省的人力 > 投入）划算 → 做。",[23,732,733],{"id":733},"怎么做",[318,735,736,739,742,745],{},[216,737,738],{},"梳理要对接的系统 + 数据流。",[216,740,741],{},"确认各系统 API。",[216,743,744],{},"开发对接。",[216,746,747],{},"测试 + 监控。",[342,749,750],{},[11,751,752],{},"广州市汉诺雷斯（HNREIS）提供系统集成（API 对接 ERP\u002F物流\u002F支付\u002FCRM），帮企业打通数据。把你的系统情况告诉我们，我们设计集成方案。",{"title":348,"searchDepth":349,"depth":349,"links":754},[755,756,757,758,762,767,768,769,770,771,772],{"id":409,"depth":349,"text":410},{"id":441,"depth":349,"text":441},{"id":450,"depth":349,"text":450},{"id":476,"depth":349,"text":476,"children":759},[760,761],{"id":479,"depth":355,"text":479},{"id":496,"depth":355,"text":496},{"id":518,"depth":349,"text":518,"children":763},[764,765,766],{"id":521,"depth":355,"text":522},{"id":539,"depth":355,"text":539},{"id":553,"depth":355,"text":553},{"id":561,"depth":349,"text":561},{"id":593,"depth":349,"text":593},{"id":626,"depth":349,"text":626},{"id":672,"depth":349,"text":672},{"id":701,"depth":349,"text":701},{"id":733,"depth":349,"text":733},"2024-05-15","老板常被 API、接口、集成这些技术词绕晕。本文用大白话讲清这些概念和企业集成场景，帮老板听懂技术沟通。",[776,779,782],{"q":777,"a":778},"API 到底是什么，大白话说？","API 是两个软件\"对话\"的通道。比如你的小程序要查物流，就通过物流公司的 API 问\"这个单号到哪了\"，物流系统通过 API 回\"已签收\"。API 让不同软件能互通数据，不用人工搬。你不用懂代码，只要知道\"API = 软件之间自动传数据的通道\"。",{"q":780,"a":781},"我们为什么要做接口集成？","因为你的多个系统要互通。比如独立站订单要进 ERP、库存要同步、物流要追踪，不集成就要人工把数据从一个系统搬到另一个（累、易错）。集成后数据自动流通，提效准确。系统越多，集成价值越大。",{"q":783,"a":784},"接口集成要多少钱？","看对接的系统数量和复杂度。对接一个系统（如 ERP）通常 1-3 万；多系统集成（ERP+物流+支付+CRM）3-8 万。集成能替代人工、提效避错，ROI 明确。",[786,787,788,789],"API接口通俗解释","什么是API","接口集成","系统对接",{},"\u002Fblog\u002Fcomparison\u002Fapi-jiekou-shiye",{"title":398,"description":774},{"loc":791},"blog\u002Fcomparison\u002Fapi-jiekou-shiye",[796,797,798],"API","概念","通俗","A7Jdt6jv4eTPYhdWviHOSLSzOR5pN0xxO_6QT9M2ODg",{"id":801,"title":802,"author":6,"body":803,"category":365,"cover":366,"date":1193,"description":1194,"draft":369,"extension":370,"faq":1195,"featured":369,"image":366,"keywords":1205,"meta":1210,"navigation":386,"path":1211,"seo":1212,"sitemap":1213,"stem":1214,"tags":1215,"updated":1193,"__hash__":1218},"blog\u002Fblog\u002Fcomparison\u002Fapi-wangguan-shi-shenme.md","API网关是什么",{"type":8,"value":804,"toc":1177},[805,812,815,818,821,831,834,837,843,847,861,865,879,883,897,901,915,919,933,937,945,948,994,997,1001,1004,1049,1074,1076,1102,1104,1140,1143,1146,1172],[11,806,807,808,811],{},"API 网关是系统架构里常见的组件，",[15,809,810],{},"通俗说就是系统的\"统一前台\"。"," 这篇讲清是什么、解决什么、要不要用。",[23,813,802],{"id":814},"api网关是什么",[11,816,817],{},"在微服务架构里，后端可能拆分成几十个甚至上百个服务。如果每个服务都直接对外提供接口，客户端要记住每个服务的地址、每个服务都要自己处理鉴权限流——这会非常混乱。API 网关就是解决这个问题的。",[11,819,820],{},"所有外部请求先到网关，网关统一处理后转发到后端：",[822,823,828],"pre",{"className":824,"code":826,"language":827},[825],"language-text","客户端 → API网关（鉴权\u002F限流\u002F监控）→ 后端服务\n","text",[829,830,826],"code",{"__ignoreMap":348},[11,832,833],{},"类比公司前台：访客（客户端请求）先到前台登记（鉴权\u002F限流），前台再引导到对应部门（转发到后端服务）。访客不用记每个部门在哪，部门也不用自己设前台。",[23,835,836],{"id":836},"网关做什么",[11,838,839,840,416],{},"API 网关的核心职责是",[15,841,842],{},"把各服务都要做的\"公共事\"统一收口",[54,844,846],{"id":845},"_1-统一入口","1. 统一入口",[213,848,849,855],{},[216,850,851,854],{},[15,852,853],{},"所有请求统一入口","：客户端只需要知道网关地址，不用记每个服务的地址。",[216,856,857,860],{},[15,858,859],{},"后端服务不直接暴露","：后端服务可以部署在内网，只把网关暴露在外网，安全风险降低。",[54,862,864],{"id":863},"_2-鉴权","2. 鉴权",[213,866,867,873],{},[216,868,869,872],{},[15,870,871],{},"统一身份验证","：所有请求的鉴权在网关统一做，比如验证 token、校验权限。",[216,874,875,878],{},[15,876,877],{},"后端不用各自鉴权","：后端服务可以信任网关已通过的请求，专注业务逻辑，不用重复写鉴权代码。",[54,880,882],{"id":881},"_3-限流","3. 限流",[213,884,885,891],{},[216,886,887,890],{},[15,888,889],{},"防止过载和恶意请求","：网关按规则限制每个客户端、每个接口的调用频率，防止恶意刷接口或突发流量压垮后端。",[216,892,893,896],{},[15,894,895],{},"保护后端","：流量超出后端承受能力时，网关可以拒绝或排队，保护后端不被打挂。",[54,898,900],{"id":899},"_4-路由转发","4. 路由转发",[213,902,903,909],{},[216,904,905,908],{},[15,906,907],{},"请求转发到对应服务","：网关根据请求路径、头部等信息，把请求转发到正确的后端服务。",[216,910,911,914],{},[15,912,913],{},"负载均衡","：一个服务有多个实例时，网关把请求分发到不同实例，提升整体处理能力。",[54,916,918],{"id":917},"_5-监控日志","5. 监控日志",[213,920,921,927],{},[216,922,923,926],{},[15,924,925],{},"统一监控和日志","：所有请求的调用量、响应时间、错误率在网关统一采集，不用每个服务各自做。",[216,928,929,932],{},[15,930,931],{},"可观测性","：网关的监控数据是排查问题、优化性能的重要依据。",[54,934,936],{"id":935},"_6-协议转换","6. 协议转换",[213,938,939],{},[216,940,941,944],{},[15,942,943],{},"不同协议转换","：客户端用 HTTP，后端用 gRPC 或 Dubbo，网关可以做协议转换，让前后端用各自适合的协议。",[23,946,947],{"id":947},"为什么用网关",[144,949,950,960],{},[147,951,952],{},[150,953,954,957],{},[153,955,956],{},"问题",[153,958,959],{},"网关解决",[160,961,962,970,978,986],{},[150,963,964,967],{},[165,965,966],{},"鉴权散在各服务",[165,968,969],{},"统一鉴权",[150,971,972,975],{},[165,973,974],{},"服务直接暴露",[165,976,977],{},"统一入口保护",[150,979,980,983],{},[165,981,982],{},"流量过载",[165,984,985],{},"限流",[150,987,988,991],{},[165,989,990],{},"监控散",[165,992,993],{},"统一监控",[11,995,996],{},"不用网关的情况下，每个服务都要自己实现鉴权、限流、监控、日志，代码重复、维护成本高，还容易出不一致的问题。网关把这些公共能力收口，后端服务可以更专注业务。",[23,998,1000],{"id":999},"用-vs-不用","用 vs 不用",[11,1002,1003],{},"网关不是所有系统都需要，要看规模和复杂度。",[144,1005,1006,1016],{},[147,1007,1008],{},[150,1009,1010,1013],{},[153,1011,1012],{},"情况",[153,1014,1015],{},"建议",[160,1017,1018,1026,1034,1042],{},[150,1019,1020,1023],{},[165,1021,1022],{},"服务少\u002F简单",[165,1024,1025],{},"不一定需要",[150,1027,1028,1031],{},[165,1029,1030],{},"微服务\u002F服务多",[165,1032,1033],{},"价值大",[150,1035,1036,1039],{},[165,1037,1038],{},"开放API",[165,1040,1041],{},"需要",[150,1043,1044,1047],{},[165,1045,1046],{},"多端接入",[165,1048,1041],{},[213,1050,1051,1057,1063,1069],{},[216,1052,1053,1056],{},[15,1054,1055],{},"服务少、简单","：比如一个单体应用就两三个接口，上不上网关差别不大，反而增加复杂度。",[216,1058,1059,1062],{},[15,1060,1061],{},"微服务、服务多","：服务一多，没有网关统一管理会很痛苦，网关价值就体现出来了。",[216,1064,1065,1068],{},[15,1066,1067],{},"开放 API","：对外提供 API 的场景，网关几乎是必需品——鉴权、限流、文档、监控都要在网关层做。",[216,1070,1071,1073],{},[15,1072,1046],{},"：APP、小程序、Web、第三方多端接入，网关统一入口能简化接入复杂度。",[23,1075,236],{"id":236},[213,1077,1078,1084,1090,1096],{},[216,1079,1080,1083],{},[15,1081,1082],{},"简单系统上重网关","：就两三个服务的简单系统，非要上 Kong 或 APISIX 这种重网关，属于过度设计，增加运维负担。",[216,1085,1086,1089],{},[15,1087,1088],{},"自己从头开发","：网关是成熟领域，有很多开源和商业产品（Kong、APISIX、云厂商网关），自己从头开发既慢又容易出问题。",[216,1091,1092,1095],{},[15,1093,1094],{},"网关成单点","：网关挂了整个系统就访问不了，必须做高可用部署（多实例、负载均衡）。",[216,1097,1098,1101],{},[15,1099,1100],{},"鉴权还散在各服务","：上了网关但鉴权还在各服务自己做，等于没用上网关的核心价值。",[23,1103,260],{"id":260},[144,1105,1106,1118],{},[147,1107,1108],{},[150,1109,1110,1113,1115],{},[153,1111,1112],{},"方案",[153,1114,272],{},[153,1116,1117],{},"成本量级",[160,1119,1120,1130],{},[150,1121,1122,1125,1128],{},[165,1123,1124],{},"开源\u002F云网关",[165,1126,1127],{},"Kong\u002FAPISIX\u002F云厂商",[165,1129,288],{},[150,1131,1132,1135,1138],{},[165,1133,1134],{},"定制集成",[165,1136,1137],{},"和业务深度集成",[165,1139,310],{},[11,1141,1142],{},"主流网关产品（Kong、APISIX）开源免费，主要成本是部署运维。云厂商的网关服务（阿里云、腾讯云、AWS）按量计费，用量不大的话成本不高。自己定制集成成本中等，适合有特殊需求的场景。",[23,1144,1145],{"id":1145},"怎么选",[318,1147,1148,1154,1160,1166],{},[216,1149,1150,1153],{},[15,1151,1152],{},"评估服务数量和复杂度","：服务多、架构复杂才考虑网关。",[216,1155,1156,1159],{},[15,1157,1158],{},"简单系统不一定需要","：两三个服务的单体应用不用上网关。",[216,1161,1162,1165],{},[15,1163,1164],{},"微服务\u002F开放API用网关","：服务多、对外开放的场景，网关价值大。",[216,1167,1168,1171],{},[15,1169,1170],{},"优先成熟产品","：用 Kong、APISIX、云厂商网关，不要自己从头开发。",[342,1173,1174],{},[11,1175,1176],{},"广州市汉诺雷斯（HNREIS）帮企业做系统架构设计，含API网关选型和集成。把你的系统需求告诉我们，我们给出架构建议。",{"title":348,"searchDepth":349,"depth":349,"links":1178},[1179,1180,1188,1189,1190,1191,1192],{"id":814,"depth":349,"text":802},{"id":836,"depth":349,"text":836,"children":1181},[1182,1183,1184,1185,1186,1187],{"id":845,"depth":355,"text":846},{"id":863,"depth":355,"text":864},{"id":881,"depth":355,"text":882},{"id":899,"depth":355,"text":900},{"id":917,"depth":355,"text":918},{"id":935,"depth":355,"text":936},{"id":947,"depth":349,"text":947},{"id":999,"depth":349,"text":1000},{"id":236,"depth":349,"text":236},{"id":260,"depth":349,"text":260},{"id":1145,"depth":349,"text":1145},"2024-05-28","API网关是系统的统一入口，负责转发、鉴权、限流和监控。本文用通俗方式讲清API网关是什么、解决什么问题、企业要不要用。",[1196,1199,1202],{"q":1197,"a":1198},"API网关是什么，简单说？","API网关是系统的\"统一前台\"——所有外部请求先到网关，网关再转发到后端服务。它统一处理鉴权、限流、监控、日志这些公共事，后端服务专注业务。类比公司前台，访客先到前台登记再进去。",{"q":1200,"a":1201},"企业一定要用API网关吗？","不一定。系统简单、服务少，不一定需要网关。服务多（微服务）、要统一鉴权限流监控、对外开放API、多端接入时，网关价值大。建议按规模和复杂度选，不要为用而用。",{"q":1203,"a":1204},"API网关要花多少钱？","看方式。用开源\u002F云网关产品（如Kong\u002FAPISIX\u002F云厂商网关）成本较低，按量或自建运维；定制集成成本中等。建议优先用成熟网关产品，而不是自己从头开发。",[1206,1207,1208,1209],"API网关","网关是什么","API管理","微服务网关",{},"\u002Fblog\u002Fcomparison\u002Fapi-wangguan-shi-shenme",{"title":802,"description":1194},{"loc":1211},"blog\u002Fcomparison\u002Fapi-wangguan-shi-shenme",[796,1216,1217],"网关","架构","CInYK4Or6VhknVKica8mjtvcuqr1CPVLRxjpJ0II3Fc",{"id":1220,"title":1221,"author":6,"body":1222,"category":365,"cover":366,"date":1562,"description":1563,"draft":369,"extension":370,"faq":1564,"featured":369,"image":366,"keywords":1574,"meta":1578,"navigation":386,"path":1579,"seo":1580,"sitemap":1581,"stem":1582,"tags":1583,"updated":1562,"__hash__":1585},"blog\u002Fblog\u002Fcomparison\u002Fbanben-kongzhi-git.md","代码版本控制（Git）是什么",{"type":8,"value":1223,"toc":1548},[1224,1231,1234,1238,1241,1247,1253,1259,1263,1267,1270,1280,1284,1287,1297,1301,1304,1318,1322,1332,1336,1406,1409,1412,1418,1424,1430,1436,1438,1456,1458,1461,1508,1511,1514,1540,1543],[11,1225,1226,1227,1230],{},"Git 是开发团队的必备工具，",[15,1228,1229],{},"通俗说是代码的\"时光机\"和\"协作台\"。"," 这篇讲清老板需要了解的。",[11,1232,1233],{},"软件开发是个高度协作的工作——几个甚至几十个开发同时改同一份代码，如果没有版本控制工具，光是\"谁改了什么\"\"怎么合并\"\"改坏了怎么回退\"这些问题就能让团队崩溃。Git 就是为了解决这些问题而生的工具，它已经成为软件开发行业的标准配置。这篇用通俗方式讲清 Git 是什么、为什么开发要用、老板需要关心什么。",[23,1235,1237],{"id":1236},"git是什么","Git是什么",[11,1239,1240],{},"Git 是代码版本控制工具，核心做三件事：",[11,1242,1243,1246],{},[15,1244,1245],{},"记录历史","——代码的每次改动都有记录（谁、什么时候、改了什么），能回到任何历史版本。相当于代码的\"时光机\"，改坏了随时回退。",[11,1248,1249,1252],{},[15,1250,1251],{},"多人协作","——多个开发同时改代码，Git 能自动合并、识别冲突。相当于代码的\"协作台\"，让团队并行开发而不互相踩踏。",[11,1254,1255,1258],{},[15,1256,1257],{},"分支","——从主线分出独立分支，在分支上做新功能，做完再合并回主线。相当于代码的\"平行宇宙\"，多个功能同时开发互不影响。",[23,1260,1262],{"id":1261},"为什么用git","为什么用Git",[54,1264,1266],{"id":1265},"_1-记录历史","1. 记录历史",[11,1268,1269],{},"代码的每一次改动（commit）都有完整记录——谁改的、什么时候改的、改了哪些文件、改了什么内容。这条记录链形成代码的完整历史。",[11,1271,1272,1275,1276,1279],{},[15,1273,1274],{},"改坏了能回退","——新功能改崩了，一条命令就能回到之前的稳定版本，不用从头再来。",[15,1277,1278],{},"知道谁改了什么","——出问题时能追溯到具体是哪次改动引入的 bug、谁改的，便于排查和复盘。历史记录还让代码审计、合规追溯成为可能——金融、医疗等强监管行业对代码变更有审计要求，Git 历史是天然的审计日志。",[54,1281,1283],{"id":1282},"_2-多人协作","2. 多人协作",[11,1285,1286],{},"没有版本控制时，多人改同一份代码要靠\"文件传来传去\"或\"共享文件夹\"，冲突频发、改动丢失、版本混乱。Git 让多人协作规范化——每个人在本地改，改完提交，Git 自动合并或识别冲突。",[11,1288,1289,1292,1293,1296],{},[15,1290,1291],{},"多人同时开发不冲突","——Git 的合并机制能自动合并不同部分的改动，相同部分的冲突会明确标出，让开发者手动解决。",[15,1294,1295],{},"合并代码规范","——通过 pull request（PR）或 merge request（MR）流程，代码合并前要经过 review（代码审查），保证质量。",[54,1298,1300],{"id":1299},"_3-分支","3. 分支",[11,1302,1303],{},"分支是 Git 的杀手级特性。从主线（main\u002Fmaster）分出独立分支，在分支上开发新功能，开发完成、测试通过后再合并回主线。",[11,1305,1306,1309,1310,1313,1314,1317],{},[15,1307,1308],{},"同时做多个功能","——开发 A 做支付功能、开发 B 做用户中心，两人各自在自己的分支上开发，互不影响。",[15,1311,1312],{},"互不影响","——某个功能开发中出了问题，不会污染主线，主线始终保持稳定。",[15,1315,1316],{},"测试稳定再合并","——功能在分支上开发测试，稳定后才合并到主线，主线始终是可发布的状态。",[54,1319,1321],{"id":1320},"_4-备份","4. 备份",[11,1323,1324,1327,1328,1331],{},[15,1325,1326],{},"代码在远程仓库备份","——本地代码 push 到远程仓库（GitHub、GitLab、Gitee），相当于异地备份。本地电脑坏了、丢了，代码还在远程仓库。",[15,1329,1330],{},"不怕丢","——多人协作时每个人都有一份完整副本，任何一份丢失都能从其他人恢复。",[23,1333,1335],{"id":1334},"git-vs-不用版本控制","Git vs 不用版本控制",[144,1337,1338,1351],{},[147,1339,1340],{},[150,1341,1342,1345,1348],{},[153,1343,1344],{},"维度",[153,1346,1347],{},"Git",[153,1349,1350],{},"不用",[160,1352,1353,1364,1375,1386,1395],{},[150,1354,1355,1358,1361],{},[165,1356,1357],{},"历史",[165,1359,1360],{},"完整记录",[165,1362,1363],{},"没有",[150,1365,1366,1369,1372],{},[165,1367,1368],{},"协作",[165,1370,1371],{},"规范",[165,1373,1374],{},"手动易冲突",[150,1376,1377,1380,1383],{},[165,1378,1379],{},"回退",[165,1381,1382],{},"能",[165,1384,1385],{},"不能",[150,1387,1388,1390,1393],{},[165,1389,1257],{},[165,1391,1392],{},"支持",[165,1394,1363],{},[150,1396,1397,1400,1403],{},[165,1398,1399],{},"专业性",[165,1401,1402],{},"行业标准",[165,1404,1405],{},"不规范",[11,1407,1408],{},"不用版本控制的开发方式现在已经很少见——连个人开发者都用 Git 管理代码。如果一个开发团队不用 Git，基本可以判断为不规范。",[23,1410,1411],{"id":1411},"老板要了解的",[11,1413,1414,1417],{},[15,1415,1416],{},"规范团队都用 Git","——这是判断开发团队专业性的基本标准。用 Git 意味着团队有规范的开发流程（分支管理、代码审查、持续集成），而不是各自为政。反映专业性。",[11,1419,1420,1423],{},[15,1421,1422],{},"代码资产","——Git 仓库是企业的重要数字资产。仓库里不只是当前代码，还有完整的开发历史、设计决策、问题修复过程。这些是企业知识资产的重要组成部分。",[11,1425,1426,1429],{},[15,1427,1428],{},"源码交付","——服务商交付源码时，Git 仓库（含完整版本记录）是重要资产。只有当前代码没有历史记录，等于丢了开发过程的上下文。规范的源码交付应该包含 Git 仓库。源码含完整版本记录。",[11,1431,1432,1435],{},[15,1433,1434],{},"协作规范","——多人开发有据可查——谁做了什么、什么时候做的、为什么这么做，都有记录。出问题能追溯，避免推诿。",[23,1437,236],{"id":236},[11,1439,1440,1443,1444,1447,1448,1451,1452,1455],{},[15,1441,1442],{},"不用版本控制","——不规范、易丢代码。现在几乎没团队这么做了，但仍有个别服务商交付\"散落的代码文件\"而不是 Git 仓库，要注意。",[15,1445,1446],{},"不提交远程","——只在本地用 Git，不 push 到远程仓库，电脑坏了代码全丢。规范的团队都有远程仓库。",[15,1449,1450],{},"不分分支","——所有改动直接在主线做，功能混在一起乱、出问题难回退。规范团队都有分支策略（如 Git Flow、GitHub Flow）。",[15,1453,1454],{},"不写提交说明","——每次提交不写说明或写\"update\"\"fix\"这种无意义内容，不知道改了什么。规范团队要求写有意义的提交说明。",[23,1457,260],{"id":260},[11,1459,1460],{},"Git 本身免费（开源），成本在团队规范使用：",[144,1462,1463,1473],{},[147,1464,1465],{},[150,1466,1467,1469,1471],{},[153,1468,269],{},[153,1470,272],{},[153,1472,275],{},[160,1474,1475,1486,1497],{},[150,1476,1477,1480,1483],{},[165,1478,1479],{},"Git工具",[165,1481,1482],{},"开源免费",[165,1484,1485],{},"免费",[150,1487,1488,1491,1494],{},[165,1489,1490],{},"托管平台",[165,1492,1493],{},"GitHub\u002FGitLab等",[165,1495,1496],{},"免费\u002F订阅",[150,1498,1499,1502,1505],{},[165,1500,1501],{},"团队规范",[165,1503,1504],{},"培训使用",[165,1506,1507],{},"低",[11,1509,1510],{},"Git 工具完全免费。托管平台有免费档（GitHub 公开仓库免费、GitLab 免费版）和付费档（私有仓库、企业版），按团队规模每月几美元到几十美元。团队规范使用要培训，但 Git 已经是开发行业基础技能，招聘时默认会，培训成本很低。",[23,1512,1513],{"id":1513},"怎么确认团队规范",[318,1515,1516,1522,1528,1534],{},[216,1517,1518,1521],{},[15,1519,1520],{},"确认团队用 Git 管理代码","——这是基本标准。问\"代码在哪个仓库\"\"分支策略是什么\"能快速判断。",[216,1523,1524,1527],{},[15,1525,1526],{},"代码在远程仓库（备份）","——有远程托管（GitHub、GitLab、Gitee 或自建），不只本地。",[216,1529,1530,1533],{},[15,1531,1532],{},"有分支和提交记录","——查看仓库历史，有没有规范的分支、有意义的提交说明、代码审查记录。",[216,1535,1536,1539],{},[15,1537,1538],{},"源码交付含 Git 仓库","——服务商交付时应该交付 Git 仓库（含完整历史），不只是当前代码文件。",[11,1541,1542],{},"按这几点核对，能快速判断开发团队是否规范。规范的 Git 使用是专业开发的基本标志，也是代码资产安全的基本保障。",[342,1544,1545],{},[11,1546,1547],{},"广州市汉诺雷斯（HNREIS）用Git规范管理代码，源码完整交付（含版本记录）。把你的项目需求告诉我们，我们规范交付。",{"title":348,"searchDepth":349,"depth":349,"links":1549},[1550,1551,1557,1558,1559,1560,1561],{"id":1236,"depth":349,"text":1237},{"id":1261,"depth":349,"text":1262,"children":1552},[1553,1554,1555,1556],{"id":1265,"depth":355,"text":1266},{"id":1282,"depth":355,"text":1283},{"id":1299,"depth":355,"text":1300},{"id":1320,"depth":355,"text":1321},{"id":1334,"depth":349,"text":1335},{"id":1411,"depth":349,"text":1411},{"id":236,"depth":349,"text":236},{"id":260,"depth":349,"text":260},{"id":1513,"depth":349,"text":1513},"2024-06-06","Git是代码版本控制工具，记录历史、支持协作和分支。本文用通俗方式讲清Git是什么、为什么开发要用、老板要了解什么。",[1565,1568,1571],{"q":1566,"a":1567},"Git是什么，简单说？","Git是代码版本控制工具，通俗说是代码的\"时光机\"和\"协作台\"——记录每次改动的历史（能回到任何版本）、多人同时改不冲突、支持分支（同时做多个功能）。开发团队用Git管理代码是行业标准。",{"q":1569,"a":1570},"老板为什么要了解Git？","Git关系到代码资产管理和交付。用Git意味着代码有完整历史、多人协作规范、源码可交付（有完整版本记录）。规范的开发团队都用Git，这反映团队专业性。源码交付时Git仓库是重要资产。",{"q":1572,"a":1573},"不用Git会怎样？","不用版本控制，代码改动没记录（改坏了回不去）、多人协作靠手动合并（易冲突丢代码）、没有分支（难同时做多功能）。现在专业开发都用Git，不用版本控制是不规范的表现。",[1347,1575,1576,1577],"版本控制","代码管理","代码版本",{},"\u002Fblog\u002Fcomparison\u002Fbanben-kongzhi-git",{"title":1221,"description":1563},{"loc":1579},"blog\u002Fcomparison\u002Fbanben-kongzhi-git",[1347,1575,1584],"开发","DDOY-P0lE1QLrLUQlE8ZQ8GpIAjcQnAG0lviW8QNo_I",{"id":1587,"title":1588,"author":6,"body":1589,"category":365,"cover":366,"date":1957,"description":1958,"draft":369,"extension":370,"faq":1959,"featured":369,"image":366,"keywords":1969,"meta":1972,"navigation":386,"path":1973,"seo":1974,"sitemap":1975,"stem":1976,"tags":1977,"updated":1957,"__hash__":1980},"blog\u002Fblog\u002Fcomparison\u002Fbendibu-vs-yunduan.md","本地部署和云部署的区别",{"type":8,"value":1590,"toc":1938},[1591,1598,1601,1605,1686,1688,1691,1694,1714,1717,1737,1739,1742,1745,1771,1774,1794,1796,1800,1811,1814,1825,1828,1836,1838,1864,1866,1913,1916,1933],[11,1592,1593,1594,1597],{},"软件部署在自己机房（本地）还是云上？",[15,1595,1596],{},"两者数据位置、成本、运维、弹性不同。"," 这篇讲清区别和选择。",[11,1599,1600],{},"很多企业在做信息化决策时，第一道选择题就是\"上云还是私有化部署\"。这件事看起来只是技术选型，实际上牵涉到数据归属、合规边界、运维投入、长期成本以及未来扩展性。如果一开始选错方向，后期再迁移会付出很大代价——数据迁移、接口改造、业务中断、人员重新培训。所以我们建议在动手之前，把两种方式的本质差异理清楚，再结合自身的数据敏感度、规模和运维能力做选择。",[23,1602,1604],{"id":1603},"本地部署-vs-云部署","本地部署 vs 云部署",[144,1606,1607,1619],{},[147,1608,1609],{},[150,1610,1611,1613,1616],{},[153,1612,1344],{},[153,1614,1615],{},"本地部署",[153,1617,1618],{},"云部署",[160,1620,1621,1632,1642,1653,1664,1675],{},[150,1622,1623,1626,1629],{},[165,1624,1625],{},"数据位置",[165,1627,1628],{},"自己机房",[165,1630,1631],{},"云厂商",[150,1633,1634,1637,1639],{},[165,1635,1636],{},"可控性",[165,1638,178],{},[165,1640,1641],{},"依赖云厂商",[150,1643,1644,1647,1650],{},[165,1645,1646],{},"初期成本",[165,1648,1649],{},"高（买服务器）",[165,1651,1652],{},"低（按需付费）",[150,1654,1655,1658,1661],{},[165,1656,1657],{},"运维",[165,1659,1660],{},"自己负责",[165,1662,1663],{},"云厂商负责部分",[150,1665,1666,1669,1672],{},[165,1667,1668],{},"弹性",[165,1670,1671],{},"难（要买硬件）",[165,1673,1674],{},"强（随时扩容）",[150,1676,1677,1680,1683],{},[165,1678,1679],{},"上线速度",[165,1681,1682],{},"慢",[165,1684,1685],{},"快",[23,1687,1615],{"id":1615},[11,1689,1690],{},"本地部署也叫私有化部署，是把软件连同数据库完整安装在客户自己机房的服务器上，所有数据从产生、存储到流转都在客户自己的硬件和网络环境里。云厂商或其他第三方无法直接访问到这些数据。",[54,1692,1693],{"id":1693},"优势",[213,1695,1696,1702,1708],{},[216,1697,1698,1701],{},[15,1699,1700],{},"数据自主","：数据完全在自己机房，物理上和网络上都可控，敏感行业（金融、政务、医疗、能源、核心商业数据）的合规要求通常通过本地部署满足。",[216,1703,1704,1707],{},[15,1705,1706],{},"完全可控","：不依赖云厂商，不会因为云厂商故障、停服、政策调整影响业务；网络策略、访问权限、加密方式都可以按自己的标准来制定。",[216,1709,1710,1713],{},[15,1711,1712],{},"长期固定成本","：初期一次性投入后，主要成本是电费、机房和运维人员工资，规模上来之后单位成本会被摊薄，长期运营相对划算。",[54,1715,1716],{"id":1716},"劣势",[213,1718,1719,1725,1731],{},[216,1720,1721,1724],{},[15,1722,1723],{},"初期贵","：要买服务器、存储、网络设备，还要准备机房或机柜、UPS、空调、带宽等配套，光硬件投入就是几万到几十万，再加上软件授权和实施，初期门槛较高。",[216,1726,1727,1730],{},[15,1728,1729],{},"要运维","：硬件会坏、系统要打补丁、网络要排查、备份要做、安全要防护，需要专门的运维人员，小企业养一支运维团队成本不低。",[216,1732,1733,1736],{},[15,1734,1735],{},"弹性差","：业务量突然上涨，本地机房很难快速扩容——采购周期、上架、配置都要时间；业务量下降，已买的硬件也退不掉，资源闲置。",[23,1738,1618],{"id":1618},[11,1740,1741],{},"云部署是把软件部署在云厂商提供的服务器上（阿里云、腾讯云、华为云、AWS 等），按使用量付费。硬件、机房、网络、基础安全都由云厂商负责，客户只关注应用本身。",[54,1743,1693],{"id":1744},"优势-1",[213,1746,1747,1753,1759,1765],{},[216,1748,1749,1752],{},[15,1750,1751],{},"初期便宜","：按需付费，不用一次性买服务器，一台云主机从几十元到几百元每月起步，小企业或初创项目几乎零门槛。",[216,1754,1755,1758],{},[15,1756,1757],{},"省运维","：云厂商负责硬件、网络、机房、基础安全，客户只需要关注应用配置和数据，运维压力大幅下降，小团队也能跑稳生产环境。",[216,1760,1761,1764],{},[15,1762,1763],{},"弹性强","：业务高峰可以临时扩容（加机器、加带宽、加存储），低谷再缩容，按实际用量结算，特别适合季节性、活动型、流量波动大的业务。",[216,1766,1767,1770],{},[15,1768,1769],{},"上线快","：开通云主机几分钟，配合容器化部署可以做到当天开服、当天上线，对快速验证、敏捷迭代非常友好。",[54,1772,1716],{"id":1773},"劣势-1",[213,1775,1776,1782,1788],{},[216,1777,1778,1781],{},[15,1779,1780],{},"数据在云","：数据物理上存在云厂商机房，依赖云厂商的安全能力和商业稳定性，敏感行业和强合规场景需要谨慎评估。",[216,1783,1784,1787],{},[15,1785,1786],{},"持续付费","：云资源按月或按年计费，长期累积下来可能比一次性买硬件更贵，规模越大、运行越久越明显。",[216,1789,1790,1793],{},[15,1791,1792],{},"合规限制","：部分行业（金融、政务、医疗、关键信息基础设施）的数据不允许上公有云，或只能上指定云、政务云、行业云。",[23,1795,1145],{"id":1145},[54,1797,1799],{"id":1798},"选本地私有化","选本地（私有化）",[213,1801,1802,1805,1808],{},[216,1803,1804],{},"数据高度敏感，比如金融交易、政务数据、医疗档案、核心商业数据、客户隐私。",[216,1806,1807],{},"要完全自主可控，对外部依赖、对供应商锁定特别敏感。",[216,1809,1810],{},"规模大、长期固定负载，本地部署的总账算下来比持续上云更划算。",[54,1812,1813],{"id":1813},"选云",[213,1815,1816,1819,1822],{},[216,1817,1818],{},"数据不敏感，或合规允许上云，希望轻装上阵。",[216,1820,1821],{},"业务有明显弹性，需要快速扩容、缩容，或处于快速验证阶段。",[216,1823,1824],{},"中小规模，没有专业的运维团队，希望把硬件和网络都外包出去。",[54,1826,1827],{"id":1827},"混合",[213,1829,1830,1833],{},[216,1831,1832],{},"敏感数据放本地（如核心交易、客户隐私），一般业务上云（如官网、营销、内部办公）。",[216,1834,1835],{},"通过专线、VPN、API 网关打通，做到\"敏感在内、弹性在外\"，是很多中大型企业的主流选择。",[23,1837,236],{"id":236},[213,1839,1840,1846,1852,1858],{},[216,1841,1842,1845],{},[15,1843,1844],{},"敏感数据上云","：忽视合规要求把不该上云的数据放公有云，可能面临监管处罚、整改甚至停业。",[216,1847,1848,1851],{},[15,1849,1850],{},"小规模本地部署","：业务量不大却硬上私有化，硬件折旧和运维成本根本摊不开，反而比上云贵。",[216,1853,1854,1857],{},[15,1855,1856],{},"只比单价不算总账","：云单价便宜不等于长期便宜，本地初期贵不等于长期贵，要按 3 年、5 年总成本（TCO）来算。",[216,1859,1860,1863],{},[15,1861,1862],{},"忽视云持续费用","：带宽、存储、CDN、增值服务都会按月累计，业务量起来后账单会快速上涨。",[23,1865,260],{"id":260},[144,1867,1868,1880],{},[147,1869,1870],{},[150,1871,1872,1875,1877],{},[153,1873,1874],{},"方式",[153,1876,272],{},[153,1878,1879],{},"成本特点",[160,1881,1882,1893,1904],{},[150,1883,1884,1887,1890],{},[165,1885,1886],{},"本地",[165,1888,1889],{},"服务器+机房+运维",[165,1891,1892],{},"初期高，长期固定",[150,1894,1895,1898,1901],{},[165,1896,1897],{},"云",[165,1899,1900],{},"按需付费",[165,1902,1903],{},"初期低，持续",[150,1905,1906,1908,1911],{},[165,1907,1827],{},[165,1909,1910],{},"敏感本地+一般云",[165,1912,310],{},[23,1914,1145],{"id":1915},"怎么选-1",[318,1917,1918,1921,1924,1927,1930],{},[216,1919,1920],{},"评估数据敏感度——是否涉及个人信息、重要数据、行业强合规。",[216,1922,1923],{},"评估规模和弹性需求——是稳定负载还是波动剧烈。",[216,1925,1926],{},"算总账（初期 + 长期 3-5 年），不只看月费。",[216,1928,1929],{},"评估运维能力——有没有专门的运维团队。",[216,1931,1932],{},"按需求选本地 \u002F 云 \u002F 混合，必要时分数据域分别部署。",[342,1934,1935],{},[11,1936,1937],{},"广州市汉诺雷斯（HNREIS）帮企业做部署方案，从云部署到本地私有化，按数据合规和成本需求选。把你的部署需求告诉我们，我们给出建议。",{"title":348,"searchDepth":349,"depth":349,"links":1939},[1940,1941,1945,1949,1954,1955,1956],{"id":1603,"depth":349,"text":1604},{"id":1615,"depth":349,"text":1615,"children":1942},[1943,1944],{"id":1693,"depth":355,"text":1693},{"id":1716,"depth":355,"text":1716},{"id":1618,"depth":349,"text":1618,"children":1946},[1947,1948],{"id":1744,"depth":355,"text":1693},{"id":1773,"depth":355,"text":1716},{"id":1145,"depth":349,"text":1145,"children":1950},[1951,1952,1953],{"id":1798,"depth":355,"text":1799},{"id":1813,"depth":355,"text":1813},{"id":1827,"depth":355,"text":1827},{"id":236,"depth":349,"text":236},{"id":260,"depth":349,"text":260},{"id":1915,"depth":349,"text":1145},"2024-06-18","软件可以部署在自己机房（本地）或云上，两者数据、成本、运维和弹性不同。本文讲清本地部署和云部署的区别和选择。",[1960,1963,1966],{"q":1961,"a":1962},"本地部署和云部署什么区别？","本地部署是软件装在自己机房的服务器上，数据在自己手里，可控但要自己买服务器和维护；云部署是装在云服务器上（阿里云\u002F腾讯云等），不用买服务器、弹性扩容、按需付费，但数据在云厂商。核心区别在数据位置和运维责任。",{"q":1964,"a":1965},"企业该选本地还是云？","看数据敏感度和需求。数据高度敏感、要完全自主（金融\u002F政务\u002F核心商业数据），选本地（私有化）；要弹性、省运维、快速上线，选云。很多企业混合——敏感本地、一般云。建议按数据合规和成本需求选。",{"q":1967,"a":1968},"本地部署比云贵吗？","看规模。本地部署要一次性买服务器（几万到几十万）+持续电费机房运维，初期贵但量大后固定；云部署按需付费，初期便宜但长期持续付费，量大可能累积贵。要算总账，不是简单比单价。",[1615,1618,1970,1971],"部署方式","私有化部署",{},"\u002Fblog\u002Fcomparison\u002Fbendibu-vs-yunduan",{"title":1588,"description":1958},{"loc":1973},"blog\u002Fcomparison\u002Fbendibu-vs-yunduan",[1978,1897,1979],"部署","选型","2aw6C_2og_Eq04KLDnHPhU-NwU6cTqAJMhy_gQJj7tc",1781688908481]