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