├── .gitignore ├── DDD ├── 1.md ├── 2.md ├── 3.md ├── 4.md ├── 5.md ├── 6.md ├── 7.md ├── 8.md ├── 9.md └── pics │ ├── 11.png │ ├── 12.png │ ├── 13.png │ ├── 14.png │ ├── 15.png │ ├── 21.png │ ├── 22.png │ ├── 23.png │ ├── 31.png │ ├── 32.png │ ├── 41.png │ ├── 42.png │ ├── 43.png │ ├── 61.png │ ├── 62.png │ ├── 71.png │ ├── 72.png │ ├── 73.png │ ├── 74.png │ ├── 75.png │ ├── 76.png │ ├── 81.png │ ├── 82.png │ ├── 83.png │ ├── 84.png │ ├── 85.png │ ├── 86.png │ ├── 87.png │ ├── 88.png │ ├── 91.jpeg │ ├── 92.jpeg │ ├── 93.png │ ├── 94.png │ └── 95.png ├── README.md ├── aigc ├── autogpt_architecture.md ├── autogpt_details.md ├── basic │ ├── 1409.0473.pdf │ ├── 1508.04025.pdf │ ├── 1706.03762.pdf │ ├── 1810.04805.pdf │ ├── 2106.09685.pdf │ ├── 2303.04226.pdf │ ├── 2305.14314.pdf │ ├── A_Review_of_Deep_Contextualized_Word_Representations.md │ ├── Attention_ Attention! _ Lil'Log.pdf │ ├── GLM-2103.10360.pdf │ ├── Improving_Language_Understanding_by_Generative_Pre-Training.pdf │ ├── Neural_Network_Models.md │ ├── README.md │ ├── The_NLP_Cookbook_Modern_Recipes_for_Transformer_Ba.pdf │ ├── activation.md │ ├── additive attention与dot-product attention.pdf │ ├── bert.md │ ├── deep_neural_networks_NLP.md │ ├── feature-based_vs_fine-tuning.md │ ├── fine_tuning.md │ ├── gelu.md │ ├── gpt-1_2_3.md │ ├── lora.md │ ├── pics │ │ ├── Bottou-Afold.png │ │ ├── Bottou-Atree.png │ │ ├── Bottou-WordSetup (1).png │ │ ├── Bottou-WordSetup.png │ │ ├── Bottou-unfold.png │ │ ├── Cho-TimePhrase-TSNE.png │ │ ├── Colbert-WordTable2.png │ │ ├── Convolutional_Neural_Network.png │ │ ├── Mikolov-AnalogyTable.png │ │ ├── Mikolov-GenderVecs.png │ │ ├── Multilayer_perceptrons.jpeg │ │ ├── Neural_Network_general.png │ │ ├── Recurrent_neural_networks.png │ │ ├── Single_layer_perceptron.png │ │ ├── Socher-BillingualTSNE.png │ │ ├── Socher-ImageClass-tSNE.png │ │ ├── Socher-ImageClassManifold.png │ │ ├── Socher-SentimentTree.png │ │ ├── Softmax_Function.png │ │ ├── Stochastic_gradient_descent.png │ │ ├── Turian-WordTSNE.png │ │ ├── activation-funcs.png │ │ ├── activation.png │ │ ├── adapter.png │ │ ├── bert_01.png │ │ ├── bert_02.png │ │ ├── bert_03.png │ │ ├── bert_04.png │ │ ├── bert_05.png │ │ ├── bert_06.png │ │ ├── bert_07.png │ │ ├── bert_08.png │ │ ├── bert_09.png │ │ ├── bert_10.png │ │ ├── bert_11.png │ │ ├── bert_12.png │ │ ├── bert_13.png │ │ ├── bert_14.png │ │ ├── bert_15.png │ │ ├── bert_16.png │ │ ├── bert_17.png │ │ ├── bert_18.png │ │ ├── bert_19.png │ │ ├── bert_20.png │ │ ├── bert_21.png │ │ ├── bert_22.png │ │ ├── bert_23.png │ │ ├── bert_24.png │ │ ├── bert_25.png │ │ ├── bert_26.png │ │ ├── bert_27.png │ │ ├── bert_28.png │ │ ├── bert_29.png │ │ ├── bert_30.png │ │ ├── bert_31.png │ │ ├── bert_32.png │ │ ├── bert_33.png │ │ ├── bert_34.png │ │ ├── bert_35.png │ │ ├── bert_36.png │ │ ├── bert_37.png │ │ ├── bert_38.png │ │ ├── bert_39.png │ │ ├── bert_40.png │ │ ├── def.png │ │ ├── diff_vectors.png │ │ ├── different-kinds-of-transfer-learning.png │ │ ├── elmo_1.png │ │ ├── elmo_10.png │ │ ├── elmo_11.png │ │ ├── elmo_12.png │ │ ├── elmo_2.png │ │ ├── elmo_3.png │ │ ├── elmo_4.png │ │ ├── elmo_5.png │ │ ├── elmo_6.png │ │ ├── elmo_7.png │ │ ├── elmo_8.png │ │ ├── elmo_9.png │ │ ├── embedding_example.png │ │ ├── embedding_parameterized.png │ │ ├── embedding_predict.png │ │ ├── exp.jpeg │ │ ├── fine_tuning.png │ │ ├── flowchart-DeViSE.png │ │ ├── flowchart-TranfserLearning2.png │ │ ├── flowchart-bilingual.png │ │ ├── full-fine-tuning.png │ │ ├── gelu.png │ │ ├── general_connection-residual_connection.png │ │ ├── gpt-1_2_3.png │ │ ├── gpt-1_2_3_a.png │ │ ├── instruction_tuning_with_pretrain–finetune_and_prompting.png │ │ ├── lora-00.png │ │ ├── lora-01.png │ │ ├── lora-02.png │ │ ├── lora-03.png │ │ ├── lora-04.png │ │ ├── lora-05.png │ │ ├── lora-06.png │ │ ├── lora-07.png │ │ ├── lora-08.png │ │ ├── lora-1.png │ │ ├── lora-2.png │ │ ├── lora-arch.png │ │ ├── mse.png │ │ ├── prefix.png │ │ ├── relu-d.png │ │ ├── relu-formula.png │ │ ├── relu-pros-cons.png │ │ ├── residual-connection.png │ │ ├── sigmoid-d.png │ │ ├── sigmoid-pros-cons.png │ │ ├── softmax-details.png │ │ ├── softmax-example.png │ │ ├── softmax-formula-exp.png │ │ ├── softmax-formula.png │ │ ├── softmax-pros-cons.png │ │ ├── tanh-d.png │ │ ├── tanh-pros-cons.png │ │ ├── the-general-connections-and-the-residual-connections.png │ │ └── word_embedding_mapping.png │ ├── rank.md │ ├── relu.md │ ├── residual_connection.md │ ├── sigmoid.md │ ├── softmax.md │ ├── tanh.md │ └── vae │ │ ├── AI艺术的背后：详解文本生成图像模型 - 知乎.pdf │ │ ├── EM算法.pdf │ │ ├── Understanding_VAE.pdf │ │ ├── VAE.pdf │ │ ├── VAE_简单推导.pdf │ │ └── VAE变分自编码器公式推导.pdf ├── langchain_details.md ├── openai_text_embedding.md ├── pics │ ├── auto_gpt_arch.svg │ ├── autonomous_AI_mechanism.png │ ├── autopgt_logic.png │ ├── bidirectional-RNN.png │ ├── chuantong.png.webp │ ├── command_prompt.png │ ├── embedding.png │ ├── fenci.gif │ ├── gpt-4_task_memory.webp │ ├── input-5.gif │ ├── input-output.png.webp │ ├── input-time.gif │ ├── input-what.gif │ ├── kantu.png.webp │ ├── llm-invoke-example.png │ ├── llm_CommaSeparatedListOutputParser.png │ ├── llm_DatetimeOutputParser.png │ ├── llm_DuckDuckGo.png │ ├── llm_PyPDFLoader.png │ ├── llm_ShellTool.png │ ├── llm_ShellTool2.png │ ├── llm_SimpleJsonOutputParser.png │ ├── llm_agent.png │ ├── llm_chain.gif │ ├── llm_chain_legacy.png │ ├── llm_chatmessage.png │ ├── llm_pdf_example.png │ ├── llm_pdfretriever.png │ ├── llm_pdfretriever2.png │ ├── llm_pydantic.png │ ├── llm_stream_example.gif │ ├── lstm-gru.png.webp │ ├── memory_history.png │ ├── models-price.png │ ├── output.gif │ ├── pinglun-hzd.png.webp │ ├── pinglun.png.webp │ ├── quedian.jpg.webp │ ├── rnn-1.gif │ ├── rnn-lstm.png.webp │ ├── rnn.webp │ ├── rnn_base.jpeg │ ├── rnn_detail.png │ ├── rnn_func.png │ ├── rnn_simple.png │ ├── rnn_t.webp │ ├── stacked-bidirectional-RNN.png │ ├── text2vector.gif │ ├── tiankong.png.webp │ └── yingyong.png.webp ├── rnn1.md ├── rnn2.md ├── rnn3.md ├── transformer │ ├── details.md │ └── pics │ │ ├── 1.png │ │ ├── 10.jpeg │ │ ├── 11.png │ │ ├── 12.png │ │ ├── 13.jpeg │ │ ├── 14.png │ │ ├── 15.jpeg │ │ ├── 16.jpeg │ │ ├── 17.png │ │ ├── 18.png │ │ ├── 19.png │ │ ├── 2.jpeg │ │ ├── 20.png │ │ ├── 21.jpeg │ │ ├── 22.jpeg │ │ ├── 23.png │ │ ├── 24.png │ │ ├── 25.jpeg │ │ ├── 26.png │ │ ├── 27.png │ │ ├── 28.jpeg │ │ ├── 29.png │ │ ├── 3.jpeg │ │ ├── 4.jpeg │ │ ├── 5.png │ │ ├── 6.png │ │ ├── 7.png │ │ ├── 8.png │ │ └── 9.png └── what_is_autogpt.md ├── apm ├── apm.md ├── pics │ ├── apk.jpg │ ├── apm-conceptual-framework.png │ ├── apm-function.jpg │ ├── cellphone-apm.jpg │ ├── compare-1.png │ ├── compare-2.png │ ├── image.png │ ├── implant.png │ ├── log.png │ ├── simulate.png │ ├── skywalking.png │ ├── snmp.png │ ├── 代码插入.png │ ├── 动态代理.png │ ├── 可视化埋点.png │ ├── 可视化埋点流程.png │ ├── 技术方案.png │ ├── 数据维度.png │ └── 静态代理.png ├── 服务端-apm.md ├── 移动应用端-apm.md └── 移动应用类型.md ├── cache ├── Queue_FIFO.md ├── Store_Indexer.md └── listers.md ├── contiv ├── README.md ├── contivk8s-cni分析.md ├── contiv基本概念分析.md ├── endpointgroup分析.md ├── netmaster分析-1.md ├── netmaster分析-2.md ├── netmaster分析-3.md ├── netplugin分析.md ├── netprofile分析.md ├── network-driver.md ├── network分析.md ├── pics │ ├── bgp-sm.png │ ├── bgp.png │ ├── contiv-dns.png │ ├── contiv-model.png │ ├── datapath-vlanbridge.png │ ├── epg-create.png │ ├── epg-delete.png │ ├── netprofile-create.png │ ├── netprofile-delete.png │ ├── network-create.png │ ├── network-delete.png │ ├── network-driver.png │ ├── ofnet-arch.jpg │ ├── ofnet-datapath.jpg │ ├── policy-create.png │ ├── policy-delete.png │ ├── rule-create.png │ └── rule-delete.png ├── policy分析.md └── rule分析.md ├── dynamic-volume-provisioner ├── Kubernetes存储概览-Volume-Provisioner代码分析.pdf ├── README.md ├── nfs-client-provisioner源码分析.webarchive └── 利用NFS动态提供Kubernetes后端存储卷.webarchive ├── k8s-operator-example ├── kube-rbac-proxy.png ├── kubebuilder-core.png ├── kustomize-base.png ├── kustomize.jpeg ├── readme.md └── readme.pdf ├── k8s ├── Kubernetes-ResourceQuota-Controller内部实现原理及源码分析.webarchive ├── api.md ├── clean-null-docker-image.sh ├── delete_terminating_namespace.sh ├── kube-proxy.md ├── kubernetes-network.md ├── nvidia-docker.md ├── pics │ ├── RR模式.png │ ├── cni_app.png │ ├── cni_kubelet.png │ ├── cni_plugin.jpg │ ├── k8s_cni_plugin.jpg │ ├── nvidia-docker-v1.0.png │ ├── nvidia-docker-v2.0.png │ ├── nvidia-docker.png │ └── package-api.png ├── rebase.md └── require-for-storage.md ├── kuryr-kubernetes ├── kuryr-cni.md ├── kuryr-k8s-controller.md └── openstack_curl.md ├── micro-service ├── f3p-ManageLayer7Traffic.pdf ├── micro-service-stack.md ├── micro-service.md └── pics │ ├── 1.png │ ├── 2.png │ ├── 3.png │ ├── 4.png │ ├── 5.jpeg │ └── 6.jpeg ├── multi-site-ha ├── msha.md └── pics │ ├── availability.jpeg │ ├── ms1.jpeg │ ├── ms2.jpeg │ ├── ms3.jpeg │ ├── ms4.jpeg │ ├── msha1.jpeg │ ├── msha10.jpeg │ ├── msha11.jpeg │ ├── msha12.jpeg │ ├── msha13.jpeg │ ├── msha14.jpeg │ ├── msha15.jpeg │ ├── msha2.jpeg │ ├── msha3.jpeg │ ├── msha4.jpeg │ ├── msha5.jpeg │ ├── msha6.jpeg │ ├── msha7.jpeg │ ├── msha8.jpeg │ ├── msha9.jpeg │ ├── s1.jpeg │ └── s2.jpeg ├── netapp-trident └── trident.md ├── openstack └── neutron │ ├── dvr.md │ ├── ip_types.md │ ├── neutron.md │ └── pics │ ├── conntrack.png │ ├── conntrack2.png │ ├── dvr.png │ ├── dvr_case1.png │ ├── dvr_case2a.png │ ├── dvr_case2b.png │ ├── dvr_case3.jpeg │ ├── dvr_ew.jpeg │ ├── dvr_ha.jpeg │ ├── dvr_sn.jpeg │ ├── flow_of_components.png │ ├── haproxy_ap.png │ ├── ip_types.jpeg │ ├── lbaas_logic.png │ ├── lbaas_service_architecture.jpeg │ ├── lbaasv2_concepts.png │ ├── netfilter.png │ ├── neutron_ha.jpeg │ ├── neutron_network_domains.png │ ├── router.jpeg │ ├── router_legacy.jpeg │ └── router_legacy_ha.jpeg ├── others ├── Software_Engineering_Advice_from_Building_Large-Scale_Distributed_Systems.pdf ├── dean-keynote-ladis2009-scalable-distributed-google.pdf ├── dual-stack-base.md ├── high-throughput-metrics.md ├── numbers-everyone-should-know.md ├── pics │ ├── dual-stack.png │ ├── dual.gif │ ├── example.png │ └── high-throughput.jpeg └── yaml.md ├── spark ├── README.md └── pics │ ├── client-mode.png │ ├── cluster-mode-on-k8s.png │ ├── cluster-mode.png │ ├── spark-operator.png │ └── spark架构原理图.jpg ├── terway ├── Terway-详解.pdf ├── pics │ ├── aly_dns.png │ ├── cni_eni.png │ ├── cni_eniip.png │ ├── cni_pod_create.png │ ├── dns.png │ ├── dns_speedup.png │ ├── ebpf.png │ ├── ebpf_iptables.png │ ├── eni_eniip.png │ ├── eni_pool.png │ ├── ip_batch_request.png │ ├── iptables.png │ ├── loadbalancer_service.png │ ├── node_local_dns.png │ ├── overlay.png │ ├── p_iptables.png │ ├── performance1.png │ ├── performance2.png │ ├── pod_network.png │ ├── resolv.png │ ├── route.png │ ├── service.png │ ├── vpc_cni.png │ └── vpc_network.png └── terway.md ├── volume ├── nfs-plugin.md ├── pv_pvc.md ├── volume.md └── volume.png ├── wait └── wait.md └── 开发环境构建 ├── Dockerfile └── dev.dockerfile /.gitignore: -------------------------------------------------------------------------------- 1 | run.sh 2 | build.sh 3 | -------------------------------------------------------------------------------- /DDD/1.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [1. DDD 领域驱动设计落地实践：六步拆解 DDD](#1-ddd-领域驱动设计落地实践六步拆解-ddd) 4 | - [1.1. 引言](#11-引言) 5 | - [1.2. 项目需求信息](#12-项目需求信息) 6 | - [1.3. DDD落地实践](#13-ddd落地实践) 7 | - [1.4. 战略设计](#14-战略设计) 8 | - [1.4.1. 业务分析](#141-业务分析) 9 | - [1.4.2. 领域建模](#142-领域建模) 10 | - [1.5. 战术设计](#15-战术设计) 11 | - [1.5.1. 微服务拆分](#151-微服务拆分) 12 | - [1.5.2. 领域分层](#152-领域分层) 13 | - [1.6. 总结](#16-总结) 14 | 15 | 16 | 17 | # 1. DDD 领域驱动设计落地实践：六步拆解 DDD 18 | 19 | 20 | ## 1.1. 引言 21 | 22 | 相信通过前面几篇文章的介绍，大家对于 DDD 的相关理论以及实践的套路有了一定的理解，但是理解 DDD 理论和实践手段是一回事，能不能把这些理论知识实际应用到我们实际工作中又是另外一回事，因此本文通过实际的业务分析把之前文章中涉及的理论和手段全部带着大家走一遍，我想通过这种方式，让大家实际的感受下 DDD 落地过程中会遇到哪些问题以及我们应该怎样去解决这些问题。 23 | 24 | 25 | ## 1.2. 项目需求信息 26 | 27 | 这里还是大家比较熟悉的电商场景来进行说明，我想这样大家比较好理解一点。在前段时间双十一，大家被各种购物优惠券的套路整的眼花缭乱，仿佛数学不好，都不配拿到最优惠的价格了。大家都在吐槽，就不能少点套路，买东西直接给我 5 折不就天下太平了吗？我想造成这种现象的原因大概就是中国电商行业的内卷吧，只有通过各种营销活动的堆积，才能让大家花更多的时间去浏览更过的商品，才能获得更好的留客以及交易。好了，跑题了，这些我们先不去关心。那我们今天就用这个折磨人的优惠券的流程作为设计实例来说明整个 DDD 的落地过程吧。优惠券的关键业务流程如下： 28 | 29 | 1. 当需要进行大促活动的时候，运营同学需要选定对应的商品，创建创建优惠券。 30 | 2. 运营同学需要创建营销活动，制定对应的营销活动规则，比如什么满减啊，跨店减啊类似这种折磨人脑细胞的规则，然后关联相应的优惠券，最后提交活动审批。审批通过后，进行营销活动发布。 31 | 3. 提交活动审批后，审批进行营销活动审批。 32 | 4. 用户在营销页面领取优惠券之后，下单购买商品之后，在付款的时候根据对应的优惠券进行付费金额计算并完成支付。 33 | 34 | ![1](pics/11.png) 35 | 36 | 37 | ## 1.3. DDD落地实践 38 | 39 | 项目背景信息我们大致了解之后，那么我们就要着手开始通过ＤＤＤ来进行领域驱动设计的过程了。其实我们学习 DDD 理论以及方法不是最终的目的，而通过它实现实际的业务复杂度治理以及优化微服务设计才是真正的目的。 40 | 41 | 42 | ## 1.4. 战略设计 43 | 44 | 在战略设计阶段，我们最主要的过程大致包括了业务场景分析、领域建模、划分边界上下文三个阶段。实际上战略设计是 DDD 过程中的核心步骤。 45 | 46 | 47 | ### 1.4.1. 业务分析 48 | 49 | 在这个阶段我们所有做的就是进行全面的业务梳理，吧业务中涉及到的所有细节都梳理出来，为后续进行领域建模分析提供足够的、全面的业务输入。经常使用到的业务场景分析方法主要包括用例分析法、事件风暴法以及四色建模法。这里我们使用事件风暴进行业务场景的分析以及梳理。 50 | 51 | 1. **事前准备** 52 | 在进行事件风暴之前我们需要进行一些准备，主要包括贴纸、笔以及讨论的会议室，会议室中最好不要有椅子，目的是想让大家都能够站立在一起、全神贯注的去进行业务讨论。 53 | 2. **邀请参会的人** 54 | 会议的参与方主要包括业务、用户、PD、研发、测试、架构师等。 55 | 3. **业务讨论** 56 | 首先确定我们今天需要讨论的业务是什么，目标是什么。像前文所说的那样，本次讨论的业务就是营销活动的优惠券业务，目标就是完成优惠券的业务梳理，确保没有业务方面的理解 gap，在团队中达成业务理解的的一致性。在这个过程中我们需要通过提问的方式来驱动交流。 57 | 58 | - 分析业务中的事件，搞清楚事件发生的前因后果，什么意思呢？就是什么动作会导致当前时间的发生，当前这个事件发生后又会导致怎样的后果。这些我们都需要梳理清楚。还有一点需要注意， 我不但要关注正常的业务流程还要关注异常的业务流程。 59 | - 寻找业务逻辑和业务规则，比如我们在提交活动前，需要确定这些优惠券适用哪些人、领取方式是怎样的以及生效事件是怎样的等等，这些都是我们在执行操作之前需要确定的业务规则。 60 | 61 | 如下图所示，我们将优惠券的业务流程进行了梳理，分别从操作人、事件、命令的方式来描述整个优惠券业务流转的过程。 62 | 63 | ![2](pics/12.png) 64 | 65 | > 注：在进行事件风暴过程中，所有的参与人都要全身投入整个过程，放下手机以及电脑，一起参与整个业务梳理过程，只有这样，事件风暴才可能有比较好的效果。 66 | 67 | 68 | ### 1.4.2. 领域建模 69 | 70 | 在前面的事件风暴业务梳理中，我们已经把优惠券业务涉及到的参与者、动作以及事件等都进行了全面的梳理。那么接下来我们就要在此基础之上进行领域建模，这是整个 DDD 的核心。 71 | 72 | 1. **领域对象分析** 73 | 74 | 如上面所示的事件风暴小黑板中的内容，我们需要在这些梳理出来的内容中找到对应的实体、值对象以及围绕这些的领域事件以及命令操作。根据分析，我们从整个业务过程中提取了优惠券、营销活动、活动审批单、活动规则、审批意见等实体以及值对象以及和这些领域对象相关的命令操作。 75 | 76 | ![3](pics/13.png) 77 | 78 | 2. **构建业务聚合** 79 | 80 | 完成领域对象分析之后，我们需要构建业务聚合。想要构建聚合，那么首先就要在实体中找到聚合根。我们先来回顾下聚合根的特点，聚合根一定是实体，那么它具有全局唯一的标识，另外它是具备生命周期的同时需要专门的模块来进行管理。根据这样的标准，在领域对象中我们发现优惠券、营销活动以及活动审批单是具备聚合根特征的，而营销规则、营销内容等是和营销活动紧密相关的，因此他们构成营销活动聚合关系。优惠券规则、优惠券类型等是和优惠券聚合根紧密相连的，所以他们构成优惠券聚合关系。同理活动审批单也会构成聚合关系。最终我们形成如下的聚合关系。 81 | 82 | ![4](pics/14.png) 83 | 84 | 获得了整个业务流程中的所有聚合后，我们需要更具业务语义上下文将具体的聚合划分到对应的上下文中，因此我们可以把优惠券的业务分为优惠券、营销活动以及审批三个限界上下文。 85 | 86 | 87 | ## 1.5. 战术设计 88 | 89 | 在战略设计阶段，我们通过事件风暴法对整体的业务进行了全部的梳理，同时构建了领域模型以及划分了边界下文。那么接下来我们就要将领域模型映射到工程结构以及代码中实现最终的实现落地。另外在这个阶段实际还有很多细节需要明确，那优惠券来说，它包含哪些属性，需要哪些领域服务，哪些需要设计为实体，哪些需要设计为值对象，这些都是需要在战术设计阶段明确下来。 90 | 91 | 92 | ### 1.5.1. 微服务拆分 93 | 94 | 我们根据已经划分的边界上下文，我们可以拆分为优惠券服务、营销活动服务以及审批中心三个微服务，至于用户支付使用这块，还是由原先已存在支付服务来完成，只是在付款核算的时候需要使用到优惠券进行最后的金额计算。 95 | 96 | 97 | ### 1.5.2. 领域分层 98 | 99 | 在领域分层方面，我们还是按照之前文章中所说的分层结构来进行，即 interfaces 层、biz 层、domain 层以及 instructure 层。每层代表的含义之前的文章中已经进行了详细的说明，大家可以翻看前面文章中的介绍，这里不再进行赘述了。 100 | 101 | 我们以优惠券为例，实际聚合中对象还需要进行进一步的细化。对于优惠券来说它实际上还有如下所示的值对象以及实体来组成实际的优惠券。同时在优惠券我们的梳理的领域服务还包括创建优惠券、查询优惠券以及修改优惠券状态，这些动作实际都应该在领域层通过领域服务的形式完成落地。而对应的 biz 层就相当于业务的编排组合，也就是实际的业务流程的串联。 102 | 103 | ![5](pics/15.png) 104 | 105 | 当我们把领域对象进行进一步的细化之后，同时把对应的领域服务敲定之后，我们可以把这些分析后的内容映射成工程分层后的代码了。如下图所示，即为优惠券的 domain 层的代码映射。 106 | 107 | 当然到这里并不意味着结束，其实在后续还有很多工作要做，比如详细设计、编写代码以及功能测试，特别实在详细设计阶段，我们还要涉及很多的细节问题的敲定，比如数据库表的设计、比如使用什么 MQ，用不用缓存，怎么保证缓存和数据库的数据一致性问题，分布式服务有没有分布式事务的问题，应该怎么解决？有没有服务幂等问题，应该怎么解决？这些都是需要在详细设计阶段进行确定的。因此 DDD 就像是框架，通过它把业务映射成为领域对象以及领域服务和领域事件，再把这些领域相关内容再读映射为实际的代码。使得我们的服务更加的逻辑清晰以及扩展性更强，但是分布式的技术实现细节，我们还是需要有对应的解决方案来进行解决。 108 | 109 | 110 | ## 1.6. 总结 111 | 112 | 本文以电商行业的营销活动中的优惠券的发放和使用作为实际案例来阐述 DDD 领域驱动设计落地实践的过程，通过整个过程的梳理，为大家提炼了整个设计过程的精要，相信大家可以按照这样的思路在实际的工作中再结合各自的业务特征应该可以真正完成整个 DDD 的实践。万事开头难，相信只要大家能够亲自去参与或者主导一个 DDD 的落地实践过程，那么对于理解 DDD 这套架构设计方法论又会进入一个新的台阶。在后面的文章中再和大家聊聊落地 DDD 过程中可能会遇到的一些问题以及软件复杂度治理的问题。 113 | 114 | > refer to: https://ost.51cto.com/posts/13360 115 | -------------------------------------------------------------------------------- /DDD/2.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [一文扫清DDD核心概念理解障碍](#一文扫清ddd核心概念理解障碍) 4 | - [领域、子域、核心域等这么多域到底怎么理解？](#领域子域核心域等这么多域到底怎么理解) 5 | - [限界上下文？限界是什么？上下文又是什么？](#限界上下文限界是什么上下文又是什么) 6 | - [总结](#总结) 7 | 8 | 9 | 10 | # 一文扫清DDD核心概念理解障碍 11 | 12 | 13 | ## 领域、子域、核心域等这么多域到底怎么理解？ 14 | 15 | 在DDD的众多概念中，首先需要搞清楚的就是到底什么是领域。因为DDD是领域驱动设计，所以领域是DDD的核心基础概念。那么到底什么是领域呢？领域是指某个业务范围以及在范围内进行的活动。根据这个定义，我们知道领域最重要的一个核心点就是范围，只有限定了问题研究的范围，才能针对具体范围内的问题进行研究分析，在后期进行微服务拆分的的时候也是根据范围来进行的。 16 | 17 | 我们开发的软件平台是为了解决用户问题，既然我们需要研究问题并解决问题，那就得先确定问题的范围到底是什么。如果我们做的是电商平台，那么我们研究的是电商这个领域或者说电商这个范围的问题，实体店内的销售情况就不是我们研究的问题范围了。因此我们可以把领域理解为我们需要解决指定业务范围内的问题域。再举个生活中的例子，派出所实际都是有自己的片区的也就是业务范围，户籍管理、治安等都是归片区的派出所负责的。这里的片区实际就是领域，派出所专注解决自己片区内的各种事项。 18 | 19 | 既然我们研究的领域确定了，或者说研究的问题域以及范围确定了，那么接下来就需要对领域进行进一步的划分和切割。实际上这和我们研究事物的一般方法手段是一致的，一旦某个问题太大无从下手的时候，都会将问题进行一步步的拆解，再逐个进行分析和解决。那么放到DDD中，我们在进行分析领域的时候，如果领域对应的业务范围过大，那么就需要对领域进行拆解划分，形成对应的子域或者说更小的问题域，所以说子域对应的是相对于领域来说，更小的业务范围以及问题域。 20 | 21 | 回到我们刚才所说的电商领域，它就是一个非常大的领域，因为电商实际还包含了商品、用户、营销、支付、订单、物流等等各种复杂的业务。因此支付域、物流域等就是相对于电商来说更小的业务范围或者更小的问题域，那么这部分领域就是对于电商这个领域的子域，相当于对电商这个业务范围的进一步的划分。 22 | 23 | ![1](pics/21.png) 24 | 25 | 搞清楚了领域和子域的区别之后，那么怎么理解核心域、通用域以及支撑域这么多其他的域呢（域太多了，我脑袋开始嗡嗡响了）？领域和子域是按照范围大小进行区分的，那么核心域、通用域等实际就是按照功能属性进行划分的。 26 | 27 | 核心域：平台的核心竞争力、最重要的业务，比如对于阿里来说，电商就是核心域。 28 | 29 | 通用域：其他子域沉淀的通用能力，没有定制化的能力，比如公司的数据中台。 30 | 31 | 支撑域：不包含核心业务能力也不是各个子域的通用能力沉淀。 32 | 33 | 那么为什么划分了子域之后，还要分什么核心域、通用域呢？实际上这样划分的目的是根据子域的属性，确定公司对于不同域的资源投入。将优势的资源投入到具备核心竞争力的域上，也是为了让产品更加具备竞争力，就是所谓的钱要花到刀刃上。 34 | 35 | 36 | ## 限界上下文？限界是什么？上下文又是什么？ 37 | 38 | 限界上下文我觉得是DDD中一个不太好理解的概念，光看这个不明觉厉的名字，甚至有点不知道它到底想表达什么样的意思。我们先来看下限界上下文的原文---Bounded Context，通过原文我们可以看得出来，实际上限界上下文这个翻译增加了我们的理解成本。而反观Bounded Context这个原文实际更好理解一点，即为有边界的上下文。这里给大家一个小建议，如果技术上某个概念不好理解，那么不妨去看看它的原文是什么，大部分情况下原文会比翻译过来的更好理解，更能反映设计者想要表达的真实含义。 39 | 40 | ![2](pics/22.png) 41 | 42 | 大家都知道我们的语言是有上下文环境的，有的时候同样一句话在不同的语言环境或者说语言上下文中，所代表的意思是不一样的。打个比方假如你有一个女朋友，你们约好晚上一起去吃饭，你在去晚上吃饭地方的路上，这个时候你收到一条来自女朋友的语音：“我已经到龙翔桥了，你出来后往苹果店走。如果你到了，我还没到，你就等着吧。如果我到了，你还没到，你就等着吧。”这里的你就等着吧，在不同的语境下包含的意思是不同的，一个是陈述事实，一个让你瑟瑟发抖。 43 | 44 | 因此，既然语言本身就有上下文，那么用通用语言描述的业务肯定也是有边界的。DDD中的限界上下文就是用来圈定业务范围的，目的是为了确保业务语言在限界上下文内的表达唯一，不会产生额外的歧义。这个时候大家会不会有另外一个问题，那么这个限界上下文到底是一个逻辑概念还是代码层面会有一个实实在在的边界呢？ 45 | 46 | 按照我自己的理解，限界上下文既是概念上的业务边界，也是代码层面的逻辑逻辑边界。为什么这么说呢？我们在进行业务划分的时候，领域划分为子域集合，子域再划分为子子域集合，那么子子域的业务边界有时候就会和限界上下文的边界重合，也就是说子子域本身就是限界上下文，那么此时限界上下文就是业务边界。在代码落地的过程中，用户服务涉及到用户的创建、用户信息的修改等操作。肯定不会到订单服务中去做这些事情。因为他们属于不同的业务域，也就是说订单相关的操作已经超越了用户的边界上下文，因此它应该在订单的边界上下文中进行。 47 | 48 | 域和边界上下文的关系是一对一或者一对多的关系，实际上我认为域和限界上下文本质上一致的，应该是为什么这么说呢，比如我们做的微服务当中用户服务，比如，肯定不会到订单服务中去做这些事情。因为他们属于不同的业务域，也就是说订单相关的操作已经超越了用户的边界上下文，因此它应该在订单的限界上下文中进行。限界上下文最主要的作用就是限定哪些业务面描述以及业务动作在这个限界当中。 49 | 50 | ![3](pics/23.png) 51 | 52 | 53 | ## 总结 54 | 55 | DDD在实际落地实践过程中会遇到各种各样的问题，首当其冲的就是一些核心概念晦涩难懂，阻碍了技术人员对DDD的理解和掌握。本文对DDD比较难理解的核心概念进行了详细的描述，相信通过本文大家对于这些核心概念的理解能够更加深入。 56 | 57 | > refer to: https://ost.51cto.com/posts/13330 58 | -------------------------------------------------------------------------------- /DDD/3.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [DDD领域驱动设计落地实践：微服务拆分之道](#ddd领域驱动设计落地实践微服务拆分之道) 4 | - [为什么要进行微服务拆分](#为什么要进行微服务拆分) 5 | - [微服务到底该怎么拆？](#微服务到底该怎么拆) 6 | - [业务能力](#业务能力) 7 | - [通用能力](#通用能力) 8 | - [微服务拆分原则](#微服务拆分原则) 9 | - [总结](#总结) 10 | 11 | 12 | 13 | # DDD领域驱动设计落地实践：微服务拆分之道 14 | 15 | 16 | ## 为什么要进行微服务拆分 17 | 18 | 在进行微服务拆分之前，我们首先应该搞清楚为什么要进行微服务拆分？微服务拆分后会带来怎样的业务价值？在后期维护上面会不会比以前的维护成本更低？我想这些问题都是架构师在实现微服务拆分之前需要回答的问题。那么我们就来先看看单体应用在业务不断发展的过程中会遇到怎样的问题。 19 | 20 | 1. 维护难 21 | 随着业务的不断发展，单体应用的功能越来越多，需求不断变化，修改不断进行，单个应用多团队维护就会出现各种团队协作问题，不知不觉中降低了产品的研发效能。而且由于各个业务模块杂糅在一起，一个需求过来后，到底改哪个团队来做，经常在开会的时候吵得脸红脖子粗，增加了时间以及沟通成本。 22 | 2. 更新难 23 | 进行需求迭代的时候，也许只修改了某个模块的功能，但是每次发布都是一整个大的包进行发布，其中构建、发包的时间成本会随着应用的迭代逐渐增加，导致整个需求上线过程变更显得十分笨重，不利于进行团队规模的敏捷开发。 24 | 3. 稳定难 25 | 由于单体应用故障隔离范围只是线程级别的，单体应用可能会由于某个模块的功能有问题而导致整个服务平台的不可用，因此平台稳定性方面显然不能满足经常变化的业务发展的需要。 26 | 27 | 鉴于上述问题，我们需要对大泥球似的单体大应用进行合理拆分，以便于适用业务的快速发展。微服务架构拆分之后，团队成员不用都围绕一个大泥球应用转了，根据拆分的不同的业务域，各自负责自己的业务域，维护起来相对来说更加方便。同事如果有需求迭代，没有功能修改的业务域可以不用发生变更，不需要进行重新部署，大大降低了修改变更导致的平台稳定性性问题。另外由于是微服务分布式架构，不再是单点应用，不再存在单点问题，性能方面也会有所提升。 28 | 29 | 30 | ## 微服务到底该怎么拆？ 31 | 32 | 当我们想清楚为什么进行微服务拆分之后，团队Boss也同意进行微服务拆分了。于是我们准备撸起袖子加油干的时候，另外一个问题又挡在我们前面，微服务到底应该怎么拆呢？或者换句话说，我们应该按照怎样的标准来进行拆分呢？如果拆分的不好，逻辑混乱的微服务还不如逻辑清晰的单体应用。这时候天空飘来了三个大字---DDD。 33 | 34 | DDD的理论中提供了我们进行领域驱动设计的指导方针，对于我们进行微服务的拆分具备天然的指导意义。比如DDD指导我们首先要对当前系统平台的业务进行全面的分析，可以通过用例分析法、事件风暴法以及四色建模法来进行业务分析，使用统一的业务语言进行业务领域划分以及边界上下文的划定，当然在这个过程中还包含了领域模型的构建，在业务分析中找到对应的实体、值对象以及聚合根，从而形成聚合，将聚合划分到边界上下文中。后面我们就可以根据边界上下文来进行具体的微服务的划分了。 35 | 36 | 笔者在实践微服务拆分的过程中主要按照业务能力、通用能力两个维度来进行具体的拆分。接下来给大家详细说明下。 37 | 38 | 39 | ## 业务能力 40 | 41 | 所谓业务能力就是平台的具体实现的业务功能是什么，这就好比在电商业务中物流域我们按照业务可以划分为仓储、运输、配送、计费等业务领域。大的领域划分出来之后，我们可以用真实的业务流程来串联这些业务领域。当业务流程经过这些业务领域的时候，必定会触发一些领域事件，经历一些业务流程，那么在这个过程中我们就可以梳理出对应的实体、值对象以及聚合根，我们将具有紧密业务逻辑关系的实体以及值对象收敛在聚合根的周围，从而形成聚合。例如在仓储领域中就会涉及到入库、库内操作以及出库这三大流程，其中入库主要包括质检、收货以及上架。这其中涉及到的实体主要用入库单、货品、操作员等，其中入库单就是聚合根，通过它可以将货品、操作员等实体以及值对象聚合起来，形成入库聚合。 42 | 43 | ![1](pics/31.png) 44 | 45 | 46 | ## 通用能力 47 | 48 | 这里的通用能力其实包含两个意思，对于微服务本身来说，通用能力就是将各个微服务都涉及到的通用能力进行抽象形成单独的微服务。但是对于整个业务平台来说，通用能力实际就是业务中台。 49 | 50 | 1. **通用服务** 51 | 所谓通用服务就是在各个微服务之间都会碰到的问题，比如说接口的鉴权、日志的监控和管理、服务状态的监控和管理以及服务幂等等分布式系统问题。因此，我们需要将这些微服务的通用服务进行统一的抽象，形成通用的基础服务，这样微服务本身只需要关注自身的业务，这些微服务通用的能力由单独的基础服务来进行实现就 OK 了。 52 | 53 | 2. **业务中台** 54 | 我们还是拿大家最熟悉的电商业务来举个栗子吧，电商的业务形态有很多种，就阿里巴巴来说，有淘宝、天猫、主打生鲜的盒马、天猫超市等等。不管上层的业务形态有怎样的变化，实际上他们都是有比较核心的业务域是通用的，比如用户、支付、仓储、物流等等。那么实际上这些通用的业务对于整个电商平台来说实际就是通用能力，因此我们需要将这些通用的公共的能力进行下沉，形成业务中台，实现企业级的通用业务能力复用。 55 | 56 | ![2](pics/32.png) 57 | 58 | 59 | ## 微服务拆分原则 60 | 61 | 在进行微服务拆分的过程中，有几条笔者总结的原则大家可以参考下，在实操的时候如果没有原则来遵循，实际我们自己也没办法去评判微服务拆分的效果到底有没有达到我们的预期。 62 | 63 | **微服务拆分要把握度** 64 | 65 | 如果在微服务拆分过程中发生过度拆分，就会导致微服务爆炸的情况。不可避免的增加软件系统的维护成本，同时由于拆分也会导致业务流程变长，原本一两个服务就完成的业务，拆分后需要在五六个甚至更多的微服务才能完成，增加了平台出现 Bug 的概率，不知不觉中降低了平台的稳定性。另外更多的微服务意味着需要更多的服务器资源，从而在无形中增加了业务成本。因此我们可以借助于 DDD 划分的边界上下文，防止微服务过度拆分情况的发生。 66 | 67 | **拆分过程逐步迭代** 68 | 69 | 软件平台架构的演进过程必定会经历现有平台以及新架构平台先共存，后替代的过程。因此我们可以先从平台的非核心功能开始再到核心功能这样逐步拆分的方式进行迭代拆分，避免一上来就要大刀阔斧的进行微服务拆分以及架构调整，否则就会陷入旧平台不稳定而新平台又不完善的尴尬处境。 70 | 71 | **确保微服务高内聚低耦合** 72 | 73 | 在进行微服务拆分之前，应该对平台进行完整的领域划分，建立合适的领域模型，确定好边界上下文，并以此作为微服务拆分的指导。将领域模型的稳定与不断变化的外部需求进行隔离，保证核心领域模型的稳定，避免领域模型之间的强依赖。从而达到实现微服务高内聚低耦合的目的。 74 | 75 | 76 | ## 总结 77 | 78 | 本文主要围绕微服务拆分在实践落地层面存在的问题进行了分析，并结合自身的实践经验，可以分别从业务能力维度以及通用能力维度两方面进行拆分，同时提出了微服务拆分的相关原则和建议。希望大家在自己的实际项目中进行微服务拆分落地的时候可以有所参考。 79 | 80 | > refer to: https://ost.51cto.com/posts/13363 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | -------------------------------------------------------------------------------- /DDD/5.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [DDD的类命名规范](#ddd的类命名规范) 4 | - [前言](#前言) 5 | - [用户界面层的类命名规范](#用户界面层的类命名规范) 6 | - [应用层的类命名规范](#应用层的类命名规范) 7 | - [领域层的类命名规范](#领域层的类命名规范) 8 | - [基础设施层的类命名规范](#基础设施层的类命名规范) 9 | - [其它的类命名规范](#其它的类命名规范) 10 | 11 | 12 | 13 | # DDD的类命名规范 14 | 15 | 16 | ## 前言 17 | 18 | 下面按照DDD分层架构进行说明： 19 | 20 | - 用户界面层 21 | - 应用层 22 | - 领域层 23 | - 基础设施层 24 | 25 | 将各个层都会用到的类归到其他的类命名规范中。 26 | 27 | 28 | ## 用户界面层的类命名规范 29 | 30 | | 类型 | 说明 | 建议命名 | 示例 | 31 | | --- | --- | --- | --- | 32 | | 控制器（Controller） | MVC控制器 | XXXController | TransferController | 33 | 34 | 35 | ## 应用层的类命名规范 36 | 37 | | 类型 | 说明 | 建议命名 | 示例 | 38 | | --- | --- | --- | --- | 39 | | 应用服务类（Application Service） | 封装了技术逻辑，协调者，调用领域层，本身不负责业务逻辑。与领域服务类（Domain Service)同名时，通过类路径来区分。 | XXXService | FundsTransferService | 40 | 41 | 42 | ## 领域层的类命名规范 43 | 44 | | 类型 | 说明 | 建议命名 | 示例 | 45 | | --- | --- | --- | --- | 46 | | 实体（Entity） | 名词 | XXX | Account
BrokderageAccount
Customer
Order
Invoice
Cargo | 47 | | 值对象（Value Object） | 名词 | XXX | Address
SalesContact
Role
| 48 | | 策略（Policy） | 业务惯例，约束 | XXXPolicy | OverbookingPolicy | 49 | | 规格（Specification） | 用于表达特定类型的规则，用来替代条件逻辑，比如“拖欠票据规格”用来验证票据是否拖欠，“大额票据规格”用来判断票据是否为大额票据。参见规格模式。 | XXXSpecification | DelinquentInvoiceSpecification
BigInvoiceSpecification
RouteSpecification | 50 | | 领域服务（Domian Service） | 封装不属于任何实体/跨实体和值对象的业务逻辑 | XXXService | RoutingService | 51 | | 领域事件类（Event） | 领域事件 | XXXEvent/过去式 | HandlingEvent
BacklogItemCommited | 52 | | 存储库（Repository） | 数据读写 | XXXRepository | InvoiceRepository
TradeOrderRepository
CargoRepository | 53 | | 工厂类（Factory） | 创建某种对象的工厂 | XXXFactory | BrokerageAcccountFactory | 54 | 55 | 原来我将 Repository 放到了基础设施层，将 Factory 放到了其它，但是出于业务逻辑内聚的考虑，还是应该将 Repository 和 Factory 放到领域层比较合适。当然非业务逻辑的 Factory 也可以归到其它。 56 | 57 | 58 | ## 基础设施层的类命名规范 59 | 60 | | 类型 | 说明 | 建议命名 | 示例 | 61 | | --- | --- | --- | --- | 62 | | 基础设施服务（Infrastructure Service） | 提供基础设施服务。与领域服务类（Domain Service）同名时，通过类路径来区分。 | XXXService | MailService
SMSService | 63 | 64 | 65 | ## 其它的类命名规范 66 | 67 | | 类型 | 说明 | 建议命名 | 示例 | 68 | | --- | --- | --- | --- | 69 | | 助手类（Helper） | 帮助完成某类操作的工具类 | XXXHelper | | 70 | | 工具类（Utils） | 工具类 | XXXUtils | | 71 | | 数据传输对象（DTO，Data Transfer Object） | 用来在各层之间传递数据的对象，不包含逻辑。 | XXXDTO | | 72 | | 视图对象（VO，View Object） | View Object本质也是一种Data Transfer Object，只不过是用在用户界面层向应用层传递数据。注意，不要和DDD的Value Object值对象搞混了。 | XXXVO | | 73 | | 持久化对象（PO，Persistence Object） | 用来持久化数据的对象，比如对关系数据库而言一个Persistence Object可能是JPA Entity对象。需要权衡是直接使用DDD Entity来作持久化，还是复制到一个新的JPA Entity中作持久化。 | XXXPO | | 74 | 75 | **领域对象（DO，Domain Object，包含Entity和Value Object）** 是否直接用在界面展示和数据持久化，还是需要复制并转换成View Object再在界面展示，或转换成Persistence Object再作数据持久化需要权衡。需要考虑： 76 | 77 | - 是否泄漏了不应该暴露的数据 （安全问题） 78 | - 是否读取或传输了过多的数据（性能问题） 79 | - 是否需要的是合并或处理后的数据（数据问题） 80 | - 对象复制的成本（性能问题） 81 | 82 | > https://blog.csdn.net/nklinsirui/article/details/117935538 83 | -------------------------------------------------------------------------------- /DDD/7.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [客户管理系统微服务化实战-PartI](#客户管理系统微服务化实战-parti) 4 | - [场景：地产 CRM](#场景地产-crm) 5 | - [使用DDD指导地产CRM系统的设计](#使用ddd指导地产crm系统的设计) 6 | - [将分析成果转化为方案域设计](#将分析成果转化为方案域设计) 7 | 8 | 9 | 10 | # 客户管理系统微服务化实战-PartI 11 | 12 | 13 | ## 场景：地产 CRM 14 | 15 | 您经营着一家房地产开发商，销售房产，迫切需要一套销售系统，考虑到微服务的优势，您决定使用微服务的方式构建系统；主要的业务流程也非常简单：用户前来购买购买产品（房产），首先需要登记用户信息，并缴纳一定数量的定金，待交易当日，挑选心仪的产品（房产），支付尾款，完成交易。 16 | 17 | 18 | ## 使用DDD指导地产CRM系统的设计 19 | 20 | 微服务系统的设计方面，领域驱动设计（Domain-Driven Design，DDD）是一个从业务出发的好选择，它由Eric Evans提出，是一种全新的系统设计和建模方法，这里的模型指的就是领域模型（Domain Model）。领域模型通过聚合（Aggregate）组织在一起，聚合间有明显的业务边界，这些边界将领域划分为一个个限界上下文（Bounded Context）。 21 | 22 | 理论概念都搞清楚了，那么怎么来找模型和聚合呢？一个非常流行的方法就是Event Storming，它是由Alberto Brandolini发明，经历了DDD社区和很多团队的实践，也是一种非常有参与感的团队活动： 23 | 24 | ![1](pics/71.png) 25 | 26 | 上图就是我们对地产CRM这个场景使用Event Storming探索的结果，现在我们能够将限界上下文清晰的梳理出来： 27 | 28 | ![2](pics/72.png) 29 | 30 | > 提示：Event Storming是一项非常有创造性的活动，也是一个持续讨论和反复改进的过程，不同的团队关注的核心域（Core Domain）不同，得到的最终结果也会有差异。我们的目的是为了演示完整的微服务系统构建的过程，并不涉及商业核心竞争力方面的探讨，因此没有Core Domain和Sub Domain之类的偏重。 31 | 32 | 33 | ## 将分析成果转化为方案域设计 34 | 35 | 当我们完成所有的限界上下文的识别后，可以直接将它们落地为微服务： 36 | 37 | ![3](pics/73.png) 38 | 39 | 1. 用户服务：提供用户信息管理服务，这里保存这用户的账号和密码，负责登录和认证； 40 | 2. 产品（房产）服务：提供产品管理服务，保存着房产的信息诸如价格、是否已售出等信息； 41 | 3. 支付服务：提供交易时支付服务，模拟对接银行支付定金，以及购房时支付尾款； 42 | 43 | 由于完成一笔交易是一个复杂的流程，与这三个微服务都有关联，因此我们引入了一个复合服务——交易服务： 44 | 45 | ![4](pics/74.png) 46 | 47 | - 交易服务：提供产品交易服务，它通过编排调用将整个交易流程串起来,交易服务中有两个流程： 48 | - 定金支付 49 | - Step1：通过用户服务验证用户身份； 50 | 51 | - Step2：通过支付服务请求银行扣款，增加定金账号内的定金； 52 | - 购房交易 53 | - Step1：通过用户服务验证用户身份； 54 | - Step2：通过资源服务确定用户希望购买的资源（房产）尚未售出； 55 | - Step3：通过资源服务标记目标资源（房产）已售出； 56 | - Step4：通过支付服务请求扣减定金账号内的定金，以及银行扣剩下的尾款； 57 | - 最后两个步骤需要保证事务一致性，其中Step4包含两个扣款操作。 58 | 59 | 之后，我们引入Edge服务提供统一入口： 60 | 61 | ![5](pics/75.png) 62 | 63 | > Edge服务：很多时候也被称为API网关（API Gateway），负责集中认证、动态路由等等； 64 | > Edge服务需要依赖服务注册-发现机制，因此同时导入了ServiceCenter。 65 | 66 | 最后还需要提供UI： 67 | 68 | ![6](pics/76.png) 69 | 70 | > 前端UI（同样以微服务方式提供）：用户交互界面; 71 | > 至此，DDD设计地产CRM的工作就结束了。 72 | 73 | > refer to: https://servicecomb.apache.org/cn/docs/crm-part-I/ 74 | -------------------------------------------------------------------------------- /DDD/8.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [DDD—领域模型映射代码结构](#ddd领域模型映射代码结构) 4 | - [一级代码目录](#一级代码目录) 5 | - [各层代码目录](#各层代码目录) 6 | 7 | 8 | 9 | # DDD—领域模型映射代码结构 10 | 11 | 12 | ## 一级代码目录 13 | 14 | 前面《DDD—分层架构，洋葱架构，六边形架构》一文中讲到，领域模型的业务逻辑从领域层，应用层到用户接口层逐层组合和封装，对外提供灵活的服务，既实现了各层的分工和解耦，也实现了各层的协作，DDD分层架构是微服务代码结构的最佳落地。 15 | 16 | ![1](pics/81.png) 17 | ![2](pics/82.png) 18 | 19 | 根据DDD的分层架构，我们可以首先根据各层的单一职责定义一级目录（各层具体的职责见《DDD—分层架构，洋葱架构，六边形架构》）如下图： 20 | - interfaces：用户接口层 21 | - application：应用层 22 | - domain：领域层 23 | - infrastructure：基础层 24 | 25 | ![3](pics/83.png) 26 | 27 | 28 | ## 各层代码目录 29 | 30 | **用户接口层：interfaces目录下的代码目录结构有assembler，dto 和facade 三类** 31 | - assembler：实现前端传输数据到后端的载体DTO和DO领域对象的转换，assembler都是和DTO和DO一起出现 32 | - dto：前端传输数据到后端的载体，不实现任何业务逻辑 33 | - facade：封装应用服务，提供粗粒度的调用接口 34 | 35 | ![4](pics/84.png) 36 | 37 | **应用层：application目录下的代码目录结构有event的订阅和发布，编排领域层的应用service，同时应用层负责与外部微服务交互，可能有DTO和DO的转换过程，需要Assembler的参与** 38 | - event.publish：存放事件发布的代码 39 | - event.subscribe：存放事件订阅的代码 40 | - service：应用服务，对多个领域服务和外部微服务调用的封装，编排和组合，对用户接口层提供流程上的核心业务逻辑 41 | 42 | ![5](pics/85.png) 43 | 44 | **领域层：domain目录下是由一个或多个独立的聚合目录构成，每一个聚合是一个独立的业务功能单元，多个聚合共同实现领域模型的核心业务逻辑，聚合文件夹可以以聚合名称命名，聚合内包含entity，event，repository和service四个子目录。** 45 | - entity：存放聚合根，实体和值对象 46 | - event：存放事件实体，以及事件的具体业务逻辑实现 47 | - service：存放跨聚合编排的领域服务，以及PO和DO转换和初始化用的工厂 48 | - repository：一个聚合只能有一个仓储，仓储一般包含仓储接口和仓储实现。同事仓储还会有DAO代码的具体实现 49 | 50 | ![6](pics/86.png) 51 | 52 | **基础层：主要存放配置信息config和各种第三工具，API，组件集成的工具类utils** 53 | 54 | ![7](pics/87.png) 55 | 56 | 领域模型映射成微服务代码结构的最终目录组织结构如下： 57 | 58 | ![8](pics/88.png) 59 | 60 | > refer to: https://www.cnblogs.com/jiyukai/p/14836825.html 61 | -------------------------------------------------------------------------------- /DDD/9.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [DDD领域驱动设计之聚合根、实体、值对象](#ddd领域驱动设计之聚合根实体值对象) 4 | - [聚合根、实体、值对象的区别？](#聚合根实体值对象的区别) 5 | - [聚合根、实体、值对象对象之间如何建立关联？](#聚合根实体值对象对象之间如何建立关联) 6 | - [如何识别聚合与聚合根？](#如何识别聚合与聚合根) 7 | - [CQRS 实战](#cqrs-实战) 8 | - [概念](#概念) 9 | - [架构图](#架构图) 10 | - [代码布局](#代码布局) 11 | - [数据模型转换](#数据模型转换) 12 | - [项目目录结构](#项目目录结构) 13 | - [总结](#总结) 14 | 15 | 16 | 17 | # DDD领域驱动设计之聚合根、实体、值对象 18 | 19 | 20 | ## 聚合根、实体、值对象的区别？ 21 | 22 | 1. 从标识的角度： 23 | 24 | 聚合根具有全局的唯一标识，而实体只有在聚合内部有唯一的本地标识，值对象没有唯一标识，不存在这个值对象或那个值对象的说法。 25 | 26 | 2. 从是否只读的角度： 27 | 28 | 聚合根除了唯一标识外，其他所有状态信息都理论上可变；实体是可变的；值对象是只读的； 29 | 30 | 3. 从生命周期的角度： 31 | 32 | 聚合根有独立的生命周期，实体的生命周期从属于其所属的聚合，实体完全由其所属的聚合根负责管理维护；值对象无生命周期可言，因为只是一个值； 33 | 34 | ![1](pics/91.jpeg) 35 | 36 | 37 | ## 聚合根、实体、值对象对象之间如何建立关联？ 38 | 39 | 聚合根到聚合根：通过ID关联； 40 | 41 | 聚合根到其内部的实体，直接对象引用； 42 | 43 | 聚合根到值对象，直接对象引用； 44 | 45 | 实体对其他对象的引用规则：1）能引用其所属聚合内的聚合根、实体、值对象；2）能引用外部聚合根，但推荐以ID的方式关联，另外也可以关联某个外部聚合内的实体，但必须是ID关联，否则就出现同一个实体的引用被两个聚合根持有，这是不允许的，一个实体的引用只能被其所属的聚合根持有； 46 | 47 | 值对象对其他对象的引用规则：只需确保值对象是只读的即可，推荐值对象的所有属性都尽量是值对象； 48 | 49 | 50 | ## 如何识别聚合与聚合根？ 51 | 52 | 明确含义：一个Bounded Context（限界上下文）可能包含多个聚合，每个聚合都有一个根实体，叫做聚合根； 53 | 54 | ![2](pics/92.jpeg) 55 | 56 | 识别顺序：先找出哪些实体可能是聚合根，再逐个分析每个聚合根的边界，即该聚合根应该聚合哪些实体或值对象；最后再划分Bounded Context； 57 | 58 | 聚合边界确定法则：根据不变性约束规则（Invariant）。不变性规则有两类：1）聚合边界内必须具有哪些信息，如果没有这些信息就不能称为一个有效的聚合；2）聚合内的某些对象的状态必须满足某个业务规则. 59 | 60 | 61 | ## CQRS 实战 62 | 63 | 64 | ### 概念 65 | 66 | CQRS(Command Query Responsibility Segregation)是将Command(命令)与Query(查询)分离的一种模式。其基本思想在于：任何一个方法都可以拆分为命令和查询两部分： 67 | 68 | Command：不返回任何结果(void)，但会改变对象的状态。Command是引起数据变化操作的总称，一般会执行某个动作，如：新增，更新，删除等操作。操作都封装在Command中，用户提交Commond到CommandBus，然后分发到对应的CommandHandler中执行。Command执行后通过Repository将数据持久化。事件源(Event source)CQRS，Command将特定的Event发送到EventBus，然后由特定的EventHandler处理。 69 | 70 | Query：返回查询结果，不会对数据产生变化的操作，只是按照某些条件查找数据。基于Query条件，返回查询结果；为不同的场景定制不同的Facade。 71 | 72 | 73 | ### 架构图 74 | 75 | 基于四层的CQRS架构图： 76 | 77 | ![3](pics/93.png) 78 | 79 | 80 | ### 代码布局 81 | 82 | **第一种是** 83 | 84 | 用户界面层调用应用服务 85 | 应用服务调用领域服务 86 | 在领域服务中 87 | ①通过仓库获取聚合根 88 | ②通过资源库持久化聚合根 89 | ③调用聚合根的业务方法 90 | ④发布领域事件 91 | 92 | **第二种是** 93 | 94 | 用户界面层调用应用服务 95 | 应用服务 96 | ①通过资源库获取聚合根 97 | ②调用聚合根的业务方法或者领域服务的方法 98 | ③通过资源库持久化聚合根 99 | ④发布领域事件 100 | 101 | 102 | ### 数据模型转换 103 | 104 | 每一层都有自己特定的数据，可以做如下区分： 105 | 106 | - VO（View Object）：视图对象，主要对应界面显示的数据对象。对于一个WEB页面，小程序，微信公众号等前端需要的数据对象。也有团队用VO表示领域层中的Value Object值对象，这个要根据团队的规范来定义。 107 | - DTO（Data Transfer Object）：数据传输对象，主要用于远程调用之间传输的对象的地方。比如我们一张表有 100 个字段，那么对应的 PO 就有 100 个属性。但是客户端只需要 10 个字段，没有必要把整个 PO 对象传递到客户端，这时我们就可以用只有这 10 个属性的 DTO 来传递结果到客户端，这样也不会暴露服务端表结构。到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为 VO。DTO泛指用于展示层与服务层之间的数据传输对象，当然VO也相当于数据DTO的一种。 108 | - DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体，使用的是充血模型设计的对象。也有团队使用用 BO（Business Objects）表示业务对象的概念。 109 | - PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。最形象的理解就是一个 PO 就是数据库中的一条记录，好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。也有团队使用DO（Data Object）表示数据对象 110 | - POJO（Plain Ordinary Java Object）：简单对象，是只具有setter getter方法对象的统称。但是不要把对象名命名成 xxxPOJO！ 111 | 112 | **模型转换架构图：** 113 | 114 | （1）从应用层->基础设施层的过程： 115 | 116 | ![4](pics/94.png) 117 | 118 | （2）从基础设施层->应用层的过程： 119 | 120 | ![5](pics/95.png) 121 | 122 | 123 | ### 项目目录结构 124 | 125 | │ 126 | │ ├─interface 用户接口层 127 | │ │ └─controller 控制器，对外提供（Restful）接口 128 | │ │ └─facade 外观模式，对外提供本地接口和dubbo接口 129 | │ │ └─mq mq消息，消费者消费外部mq消息 130 | │ │ 131 | │ ├─application 应用层 132 | │ │ ├─assembler 装配器 133 | │ │ ├─dto 数据传输对象，xxxCommand/xxxQuery/xxxVo 134 | │ │ │ ├─command 接受增删改的参数 135 | │ │ │ ├─query 接受查询的参数 136 | │ │ │ ├─vo 返回给前端的vo对象 137 | │ │ ├─service 应用服务，负责领域的组合、编排、转发、转换和传递 138 | │ │ ├─repository 查询数据的仓库接口 139 | │ │ ├─listener 事件监听定义 140 | │ │ 141 | │ ├─domain 领域层 142 | │ │ ├─entity 领域实体 143 | │ │ ├─valueobject 领域值对象 144 | │ │ ├─service 领域服务 145 | │ │ ├─repository 仓库接口，增删改的接口 146 | │ │ ├─acl 防腐层接口 147 | │ │ ├─event 领域事件 148 | │ │ 149 | │ ├─infrastructure 基础设施层 150 | │ │ ├─converter 实体转换器 151 | │ │ ├─repository 仓库 152 | │ │ │ ├─impl 仓库实现 153 | │ │ │ ├─mapper mybatis mapper接口 154 | │ │ │ ├─po 数据库orm数据对象 155 | │ │ ├─ack 实体转换器 156 | │ │ ├─mq mq消息 157 | │ │ ├─cache 缓存 158 | │ │ ├─util 工具类 159 | │ │ 160 | │ 161 | 162 | 163 | ## 总结 164 | 165 | 1. MVC是一个短暂的快乐但不足以支撑漫长的生活，而DDD是一个不要短暂的温存而是一世的陪伴，如果是你来抉择你会选择哪一个？ 166 | 2. MVC的开发模式：是数据驱动，自低向上的思想，关注数据。DDD的开发模式：是领域驱动，自顶向下，关注业务活动。为了应对业务快速变化的软件系统，DDD是面向对象的最终体现，大家一起用起来吧！ 167 | 3. DDD是一套方法论，一千个读者一千个哈姆雷特。 168 | -------------------------------------------------------------------------------- /DDD/pics/11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/11.png -------------------------------------------------------------------------------- /DDD/pics/12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/12.png -------------------------------------------------------------------------------- /DDD/pics/13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/13.png -------------------------------------------------------------------------------- /DDD/pics/14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/14.png -------------------------------------------------------------------------------- /DDD/pics/15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/15.png -------------------------------------------------------------------------------- /DDD/pics/21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/21.png -------------------------------------------------------------------------------- /DDD/pics/22.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/22.png -------------------------------------------------------------------------------- /DDD/pics/23.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/23.png -------------------------------------------------------------------------------- /DDD/pics/31.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/31.png -------------------------------------------------------------------------------- /DDD/pics/32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/32.png -------------------------------------------------------------------------------- /DDD/pics/41.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/41.png -------------------------------------------------------------------------------- /DDD/pics/42.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/42.png -------------------------------------------------------------------------------- /DDD/pics/43.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/43.png -------------------------------------------------------------------------------- /DDD/pics/61.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/61.png -------------------------------------------------------------------------------- /DDD/pics/62.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/62.png -------------------------------------------------------------------------------- /DDD/pics/71.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/71.png -------------------------------------------------------------------------------- /DDD/pics/72.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/72.png -------------------------------------------------------------------------------- /DDD/pics/73.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/73.png -------------------------------------------------------------------------------- /DDD/pics/74.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/74.png -------------------------------------------------------------------------------- /DDD/pics/75.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/75.png -------------------------------------------------------------------------------- /DDD/pics/76.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/76.png -------------------------------------------------------------------------------- /DDD/pics/81.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/81.png -------------------------------------------------------------------------------- /DDD/pics/82.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/82.png -------------------------------------------------------------------------------- /DDD/pics/83.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/83.png -------------------------------------------------------------------------------- /DDD/pics/84.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/84.png -------------------------------------------------------------------------------- /DDD/pics/85.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/85.png -------------------------------------------------------------------------------- /DDD/pics/86.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/86.png -------------------------------------------------------------------------------- /DDD/pics/87.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/87.png -------------------------------------------------------------------------------- /DDD/pics/88.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/88.png -------------------------------------------------------------------------------- /DDD/pics/91.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/91.jpeg -------------------------------------------------------------------------------- /DDD/pics/92.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/92.jpeg -------------------------------------------------------------------------------- /DDD/pics/93.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/93.png -------------------------------------------------------------------------------- /DDD/pics/94.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/94.png -------------------------------------------------------------------------------- /DDD/pics/95.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/DDD/pics/95.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [work-notes](#work-notes) 4 | - [AIGC](#aigc) 5 | - [APM](#apm) 6 | - [容器相关](#容器相关) 7 | - [DDD](#ddd) 8 | - [others](#others) 9 | 10 | 11 | - [work-notes](#work-notes) 12 | - [AIGC](#aigc) 13 | - [APM](#apm) 14 | - [容器相关](#容器相关) 15 | - [others](#others) 16 | 17 | 18 | 19 | 20 | # work-notes 21 | 22 | 好记性不如烂笔头 23 | 24 | 25 | ## AIGC 26 | 27 | - [basic knowledge](aigc/basic) 28 | - [openai embedding 详解](aigc/openai_text_embedding.md) 29 | - [what is autogpt](aigc/what_is_autogpt.md) 30 | - [autogpt 架构详解](aigc/autogpt_architecture.md) 31 | - [autogpt 源码详解](aigc/autogpt_details.md) 32 | - [transformer 理解](aigc/transformer/details.md) 33 | - [一文搞懂RNN（循环神经网络）基础篇](aigc/rnn1.md) 34 | - [循环神经网络 – Recurrent Neural Network | RNN](aigc/rnn2.md) 35 | - [RNN 扩展](aigc/rnn3.md) 36 | - [A Complete LangChain Guide](aigc/langchain_details.md) 37 | - Computer Vision 38 | - VAE 39 | - [通熟易懂 VAE](aigc/basic/vae/VAE.pdf) 40 | - [Understanding VAE](aigc/basic/vae/Understanding_VAE.pdf) 41 | - [VAE 简单推导](aigc/basic/vae/VAE_简单推导.pdf) 42 | - [VAE 变分自编码公式推导](aigc/basic/vae/VAE变分自编码器公式推导.pdf) 43 | - [EM算法](aigc/basic/vae/EM算法.pdf) 44 | - [AI艺术的背后：详解文本生成图像模型](aigc/basic/vae/AI艺术的背后：详解文本生成图像模型%20-%20知乎.pdf) 45 | 46 | 47 | ## APM 48 | 49 | - [基本概念](apm/apm.md) 50 | - [服务端 apm](apm/服务端-apm.md) 51 | - [移动应用端 apm](apm/移动应用端-apm.md) 52 | 53 | 54 | ## 容器相关 55 | 56 | - 阿里云 terway 详解 57 | - [阿里云 terway 详解](terway/terway.md) 58 | - [ppt slide: 阿里云如何构建高性能云原生容器网络](terway/Terway-详解.pdf) 59 | - openstack neutron 网络分析 60 | - [云计算几个 ip 的概念](openstack/neutron/ip_types.md) 61 | - [neutron networking architecture](openstack/neutron/neutron.md) 62 | - [openstack 分布式虚拟路由](openstack/neutron/dvr.md) 63 | - [netapp trident 源码分析](netapp-trident/trident.md) 64 | - [异地多活](multi-site-ha/msha.md) 65 | - kuryr-kubernetes 66 | - [openstack curl](kuryr-kubernetes/openstack_curl.md) 67 | - [kuryr k8s controller](kuryr-kubernetes/kuryr-k8s-controller.md) 68 | - [kuryr cni](kuryr-kubernetes/kuryr-cni.md) 69 | - k8s operator 分析和 example 详解 70 | - [markdown: k8s operator 分析和 example 详解](k8s-operator-example/readme.md) 71 | - [pdf: k8s operator 分析和 example 详解](k8s-operator-example/readme.pdf) 72 | - [contiv 分析](contiv/README.md) 73 | - k8s cache 分析 74 | - [store_indexer](cache/Store_Indexer.md) 75 | - [queue_fifo](cache/Queue_FIFO.md) 76 | - [listers](cache/listers.md) 77 | - dynamic-volume-provisioner 78 | - [nfs-client-provisioner源码分析](dynamic-volume-provisioner/nfs-client-provisioner源码分析.webarchive) 79 | - [利用NFS动态提供Kubernetes后端存储卷](dynamic-volume-provisioner/利用NFS动态提供Kubernetes后端存储卷.webarchive) 80 | - [Kubernetes存储概览-Volume-Provisioner代码分析](dynamic-volume-provisioner/Kubernetes存储概览-Volume-Provisioner代码分析.pdf) 81 | - k8s volume 分析 82 | - [k8s volume 详解](volume/volume.md) 83 | - [pv & pvc](volume/pv_pvc.md) 84 | - [k8s nfs volume 详解](volume/nfs-plugin.md) 85 | - [k8s wait package 分析](wait/wait.md) 86 | - [k8s api 机制](k8s/api.md) 87 | - [kube-proxy 关键代码流程分析](k8s/kube-proxy.md) 88 | - [Kubernetes ResourceQuota Controller内部实现原理及源码分析](k8s/Kubernetes-ResourceQuota-Controller内部实现原理及源码分析.webarchive) 89 | - [k8s rebase 的流程概要](k8s/rebase.md) 90 | - [k8s 对存储的要求](k8s/require-for-storage.md) 91 | - cni 相关 92 | - [k8s cni 相关](k8s/kubernetes-network.md) 93 | - [kuryr-cni分析](kuryr-kubernetes/kuryr-cni.md) 94 | - [contivk8s-cni分析](contiv/contivk8s-cni%E5%88%86%E6%9E%90.md) 95 | - [macvlan cni 分析](https://github.com/keontang/knowhow/blob/main/ipvlan-macvlan/macvlan-cni.md) 96 | - [nvidia docker 介绍](k8s/nvidia-docker.md) 97 | - [clean null docker image script](k8s/clean-null-docker-image.sh) 98 | - [delete terminating namespace script](k8s/delete_terminating_namespace.sh) 99 | 100 | 101 | ## DDD 102 | 103 | - [强烈推荐 awesome-go-education 中的 DDD](https://mehdihadeli.github.io/awesome-go-education/ddd/) 104 | - [DDD 领域驱动设计落地实践：六步拆解 DDD](DDD/1.md) 105 | - [一文扫清DDD核心概念理解障碍](DDD/2.md) 106 | - [DDD领域驱动设计落地实践：微服务拆分之道](DDD/3.md) 107 | - [可落地的DDD编码实践（代码结构）](DDD/4.md) 108 | - [DDD的类命名规范](DDD/5.md) 109 | - [领域驱动模型 VO、DTO、DO、PO 概念及其区别](DDD/6.md) 110 | - [客户管理系统微服务化实战-PartI](DDD/7.md) 111 | - [领域模型映射代码结构](DDD/8.md) 112 | - [DDD领域驱动设计之聚合根、实体、值对象](DDD/9.md) 113 | 114 | 115 | ## others 116 | 117 | - [ipv4 & ipv6 双栈](others/dual-stack-base.md) 118 | - [Numbers Everyone Should Know](others/numbers-everyone-should-know.md) 119 | - [一文搞懂高并发性能指标：QPS、TPS、RT、并发数、吞吐量，以及计算公式](others/high-throughput-metrics.md) 120 | - [yaml 格式中字符串跨多行的格式方法](others/yaml.md) 121 | - [spark 介绍](spark/README.md) 122 | - [knowhow](https://github.com/keontang/knowhow) 123 | - [Software Engineering Advice from Building Large-Scale Distributed Systems (Jeff Dean)](others/Software_Engineering_Advice_from_Building_Large-Scale_Distributed_Systems.pdf) 124 | - [Designs, Lessons and Advice from Building Large Distributed Systems(Jeff Dean)](others/dean-keynote-ladis2009-scalable-distributed-google.pdf) 125 | -------------------------------------------------------------------------------- /aigc/basic/1409.0473.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/1409.0473.pdf -------------------------------------------------------------------------------- /aigc/basic/1508.04025.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/1508.04025.pdf -------------------------------------------------------------------------------- /aigc/basic/1706.03762.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/1706.03762.pdf -------------------------------------------------------------------------------- /aigc/basic/1810.04805.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/1810.04805.pdf -------------------------------------------------------------------------------- /aigc/basic/2106.09685.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/2106.09685.pdf -------------------------------------------------------------------------------- /aigc/basic/2303.04226.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/2303.04226.pdf -------------------------------------------------------------------------------- /aigc/basic/2305.14314.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/2305.14314.pdf -------------------------------------------------------------------------------- /aigc/basic/A_Review_of_Deep_Contextualized_Word_Representations.md: -------------------------------------------------------------------------------- 1 | # A Review of Deep Contextualized Word Representations 2 | 3 | ![elmo_1](pics/elmo_1.png) 4 | ![elmo_2](pics/elmo_2.png) 5 | ![elmo_3](pics/elmo_3.png) 6 | ![elmo_4](pics/elmo_4.png) 7 | ![elmo_5](pics/elmo_5.png) 8 | ![elmo_6](pics/elmo_6.png) 9 | ![elmo_7](pics/elmo_7.png) 10 | ![elmo_8](pics/elmo_8.png) 11 | ![elmo_9](pics/elmo_9.png) 12 | ![elmo_10](pics/elmo_10.png) 13 | ![elmo_11](pics/elmo_11.png) 14 | ![elmo_12](pics/elmo_12.png) 15 | -------------------------------------------------------------------------------- /aigc/basic/Attention_ Attention! _ Lil'Log.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/Attention_ Attention! _ Lil'Log.pdf -------------------------------------------------------------------------------- /aigc/basic/GLM-2103.10360.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/GLM-2103.10360.pdf -------------------------------------------------------------------------------- /aigc/basic/Improving_Language_Understanding_by_Generative_Pre-Training.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/Improving_Language_Understanding_by_Generative_Pre-Training.pdf -------------------------------------------------------------------------------- /aigc/basic/README.md: -------------------------------------------------------------------------------- 1 | - [Resizual Connection](./resizual_connection.md) 2 | - [Neural Network Models](./Neural_Network_Models.md) 3 | - [applying deep neural networks to natural language processing](./deep_neural_networks_NLP.md) 4 | - [Feature-based vs Fine-tuning](./feature-based_vs_fine-tuning.md) 5 | - [矩阵的“秩”最通俗易懂的解释](./rank.md) 6 | 7 | - Activation functions 8 | - [activation](./activation.md) 9 | - [relu](./relu.md) 10 | - [sigmoid](./sigmoid.md) 11 | - [tanh](./tanh.md) 12 | - [softmax](./softmax.md) 13 | - [gelu](./gelu.md) 14 | 15 | - Attention 16 | - [Attention? Attention!](./Attention_%20Attention!%20_%20Lil'Log.pdf) 17 | - [additive attention vs dot-product attention](./additive%20attention与dot-product%20attention.pdf) 18 | - [NEURAL MACHINE TRANSLATION BY JOINTLY LEARNING TO ALIGN AND TRANSLATE](./1409.0473.pdf) 19 | - [Effective Approaches to Attention-based Neural Machine Translation](./1508.04025.pdf) 20 | - [Attention Is All You Need](./1706.03762.pdf) 21 | - [BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding](./1810.04805.pdf) 22 | 23 | - [BERT ppt](./bert.md) 24 | 25 | - GPT 26 | - [**GPT-1:** Improving Language Understanding by Generative Pre-Training](./Improving_Language_Understanding_by_Generative_Pre-Training.pdf) 27 | - [gpt-1 vs gpt-2 vs gpt-3](./gpt-1_2_3.md) 28 | 29 | - Fine Tuning 30 | - [通俗解读大模型微调(Fine Tuning)](./fine_tuning.md) 31 | - [大模型低秩适配器LoRA](./lora.md) 32 | 33 | - Other papers 34 | - [GLM](./GLM-2103.10360.pdf) 35 | - [The_NLP_Cookbook_Modern_Recipes_for_Transformer](./The_NLP_Cookbook_Modern_Recipes_for_Transformer_Ba.pdf) 36 | - [A_Review_of_Deep_Contextualized_Word_Representations](./A_Review_of_Deep_Contextualized_Word_Representations.md) 37 | - [Lora](./2106.09685.pdf) 38 | - [QLora](./2305.14314.pdf) 39 | - [A Comprehensive Survey of AI-Generated Content (AIGC): A History of Generative AI from GAN to ChatGPT](./2303.04226.pdf) 40 | -------------------------------------------------------------------------------- /aigc/basic/The_NLP_Cookbook_Modern_Recipes_for_Transformer_Ba.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/The_NLP_Cookbook_Modern_Recipes_for_Transformer_Ba.pdf -------------------------------------------------------------------------------- /aigc/basic/activation.md: -------------------------------------------------------------------------------- 1 | # activation 2 | 3 | 激活函数，并不是去激活什么，而是指如何把“激活的神经元的特征”通过函数把特征保留并映射出来，即负责将神经元的输入映射到输出端。 4 | 5 | ## 为什么需要激活函数 6 | 7 | 相比于人类大脑中基于神经元的模型，激活函数是决定向下一个神经元传递何种信息的单元，这也正是激活函数在人工神经网络中的作用。激活函数接收前一个单元输出的信号，并将其转换成某种可以被下一个单元接收的形式。 8 | 9 | ![activation](pics/activation.png) 10 | 11 | 如上图所示，神经网络中的每个神经元节点接受上一层神经元的输出值作为本神经元的输入值，并将输入值传递给下一层，输入层神经元节点会将输入属性值直接传递给下一层（隐层或输出层）。在多层神经网络中，上层节点的输出和下层节点的输入之间具有一个函数关系，这个函数称为激活函数。 12 | 13 | **简单来说，激活函数，并不是去激活什么，而是指如何把“激活的神经元的特征”通过函数把特征保留并映射出来，即负责将神经元的输入映射到输出端。** 14 | 15 | 常见激活函数如下： 16 | 17 | ![activation-funcs](pics/activation-funcs.png) 18 | 19 | **右饱和：** 20 | 当x趋向于正无穷时，函数的导数趋近于0，此时称为右饱和。 21 | **左饱和：** 22 | 当x趋向于负无穷时，函数的导数趋近于0，此时称为左饱和。 23 | **饱和函数和非饱和函数：** 24 | 当一个函数既满足右饱和，又满足左饱和，则称为饱和函数，否则称为非饱和函数。 25 | 26 | 激活函数可以分两大类： 27 | - 饱和激活函数： sigmoid、 tanh 28 | - 非饱和激活函数: ReLU 29 | 30 | 相较于饱和激活函数，非饱和激活函数可以解决“梯度消失”的问题，加快收敛。尤其对于深度神经网络【层数非常多！！】的“梯度消失”问题。 31 | 32 | ## 理想激活函数的特点 33 | 34 | 1. 能避免梯度消失问题。 35 | 36 | 2. 以零为中心：激活函数的输出应对称于零，这样梯度就不会向特定方向移动。 37 | 38 | 3. 计算成本：网络的每一层都会应用激活函数，它在深层网络中需要计算数百万次。因此，激活函数的计算成本应该很低。 39 | 40 | 4. 可微性：神经网络使用梯度下降过程进行训练，因此模型中的层需要可微或至少部分可微。这是一个函数可以作为激活函数层的必要条件。 41 | 42 | ## 激活函数为什么使用非线性函数 43 | 44 | 激活函数为什么要使用非线性函数？要解释这个问题，可以反过来思考一下，为什么激活函数不能使用线性函数。 45 | 46 | 如果使用线性函数，每一层输出都是上层输入的线性函数，无论神经网络有多少层，输出都是输入的线性组合。加深神经网络的层数就没有什么意义了。线性函数的问题在于不管加深层数到多少，总是存在与之等效的「无隐藏层」的神经网络。为了稍微直观的理解这一点，考虑下面一个简单的例子。 47 | 48 | 存在一个线性函数 `f(x)=kx(k≠0)` 作为激活函数，将 `y=f(f(f(x)))` 对应三层的神经网络。很明显可以想到同样的处理可以由 `y=ax(a=k^3)`，一个没有隐藏层的神经网络来表示。该例子仅仅是一个近似，实际中的神经网络的运算要比这个例子复杂很多，但不影响结论的成立。也就是说，使用线性激活函数时，无法发挥多层网络带来的优势。 49 | 50 | **相反如果使用非线性函数，激活函数给神经元引入了非线性因素，使得神经网络可以任意逼近任何非线性函数，这样神经网络就可以应用到众多的非线性模型中。** 51 | 52 | ## sigmoid 53 | 54 | ![sigmoid](pics/sigmoid-d.png) 55 | 56 | **可以看出sigmoid的导数最大值为0.25，在进行反向传播时，各层的梯度（均小于0.25）相乘很容易造成梯度为0，也就是“梯度消失”。** 这样，几乎就没有梯度信号通过神经元传递到前面层的梯度更新中，因此这时前面层的权值几乎没有更新，这就叫梯度消失。 57 | 58 | **二分类问题（例如判断物体是否是猫猫）：使用 `sigmoid` 函数返回概率。** 59 | **多分类问题（返回物体是每个类别的概率）：使用 `softmax` 函数，概率总和为1。** 60 | 61 | ## tanh 62 | 63 | ![tanh](pics/tanh-d.png) 64 | 65 | 可以看出，相较于Sigmoid函数有所改善，但导数仍小于1，不能避免梯度消失的情况。 66 | 67 | ## relu 68 | 69 | ![relu](pics/relu-d.png) 70 | 71 | **隐藏层的默认推荐激活函数为 ReLU(Rectified Linear Unit)。** 72 | 73 | - ReLU 在大于0时展示的线性特征能很好的解决梯度消失问题。 74 | - 与前两者相比，计算复杂度低。 75 | - 整体的非线性，能拟合任何复杂的连续函数。 76 | - 单侧抑制，可以对神经元进行筛选，让模型训练鲁棒性更强。 77 | - 神经元”熄灭“。relu在训练的时很“脆弱”。当输入值为负时，输出值和导数(梯度)均为0，意味着神经元”熄灭“，且在反向传播过程中不产生任何梯度调整值。之后的神经元梯度永远为0，不再对任何数据有所响应，导致相应参数永远不会被更新。 78 | -------------------------------------------------------------------------------- /aigc/basic/additive attention与dot-product attention.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/additive attention与dot-product attention.pdf -------------------------------------------------------------------------------- /aigc/basic/bert.md: -------------------------------------------------------------------------------- 1 | # BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding 2 | 3 | ![](pics/bert_01.png) 4 | ![](pics/bert_02.png) 5 | ![](pics/bert_03.png) 6 | ![](pics/bert_04.png) 7 | ![](pics/bert_05.png) 8 | ![](pics/bert_06.png) 9 | ![](pics/bert_07.png) 10 | ![](pics/bert_08.png) 11 | ![](pics/bert_09.png) 12 | ![](pics/bert_10.png) 13 | ![](pics/bert_11.png) 14 | ![](pics/bert_12.png) 15 | ![](pics/bert_13.png) 16 | ![](pics/bert_14.png) 17 | ![](pics/bert_15.png) 18 | ![](pics/bert_16.png) 19 | ![](pics/bert_17.png) 20 | ![](pics/bert_18.png) 21 | ![](pics/bert_19.png) 22 | ![](pics/bert_20.png) 23 | ![](pics/bert_21.png) 24 | ![](pics/bert_22.png) 25 | ![](pics/bert_23.png) 26 | ![](pics/bert_24.png) 27 | ![](pics/bert_25.png) 28 | ![](pics/bert_26.png) 29 | ![](pics/bert_27.png) 30 | ![](pics/bert_28.png) 31 | ![](pics/bert_29.png) 32 | ![](pics/bert_30.png) 33 | ![](pics/bert_31.png) 34 | ![](pics/bert_32.png) 35 | ![](pics/bert_33.png) 36 | ![](pics/bert_34.png) 37 | ![](pics/bert_35.png) 38 | ![](pics/bert_36.png) 39 | ![](pics/bert_37.png) 40 | ![](pics/bert_38.png) 41 | ![](pics/bert_39.png) 42 | ![](pics/bert_40.png) 43 | -------------------------------------------------------------------------------- /aigc/basic/feature-based_vs_fine-tuning.md: -------------------------------------------------------------------------------- 1 | # feature-based vs fine-tuning 2 | 3 | ![different-kinds-of-transfer-learning](pics/different-kinds-of-transfer-learning.png) 4 | 5 | **Feature extraction transfer learning** is when you take the underlying patterns (also called weights) of a pretrained model and adjust its outputs to be more suited to your problem. 6 | 7 | For example, say the pretrained model you were using had 236 different layers (EfficientNetB0 has 236 layers), and the top layer outputs 1000 classes because it was pretrained on ImageNet. To adjust this to your own problem, you might remove the original activation layer and replace it with your own but with the right number of output classes. The important part here is that only the top few layers become trainable, the rest remain frozen. 8 | 9 | This way all the underlying patterns remain in the rest of the layers and you can utilise them for your own problem. This kind of transfer learning is very helpful when your data is similar to the data a model has been pretrained on. 10 | 11 | **Fine-tuning transfer learning** is when you take the underlying patterns (also called weights) of a pretrained model and adjust (fine-tune) them to your own problem. 12 | 13 | This usually means training some, many or all of the layers in the pretrained model. This is useful when you've got a large dataset (e.g. 100+ images per class) where your data is slightly different to the data the original model was trained on. 14 | 15 | A common workflow is to "freeze" all of the learned patterns in the bottom layers of a pretrained model so they're untrainable. And then train the top 2-3 layers of so the pretrained model can adjust its outputs to your custom data (**feature extraction**). 16 | 17 | After you've trained the top 2-3 layers, you can then gradually "unfreeze" more and more layers and run the training process on your own data to further **fine-tune** the pretrained model. 18 | 19 | The lower a layer is in a computer vision model as in, the closer it is to the input layer, the larger the features it learn. For example, a bottom layer in a computer vision model to identify images of cats or dogs might learn the outline of legs, where as, layers closer to the output might learn the shape of teeth. Often, you'll want the larger features (learned patterns are also called features) to remain, since these are similar for both animals, where as, the differences remain in the more fine-grained features. 20 | 21 | Instruction tuning is a simple method that, as depicted in the following picture, combines appealing aspects of both the pretrain–finetune and prompting paradigms by using supervision via finetuning to improve language model’s responses to inference-time text interactions. 22 | 23 | ![Comparing instruction tuning with pretrain–finetune and prompting](pics/instruction_tuning_with_pretrain–finetune_and_prompting.png) 24 | -------------------------------------------------------------------------------- /aigc/basic/fine_tuning.md: -------------------------------------------------------------------------------- 1 | # 通俗解读大模型微调(Fine Tuning) 2 | 3 | > refer to: https://www.wehelpwin.com/article/4231 4 | 5 | 用好大模型的第一个层次，是掌握提示词工程(Prompt Engineering) ，《人人都需要掌握的Prompt Engineering技巧》一文中有详细的介绍，这里不再赘述。 6 | 7 | 用好大模型的第二个层次，是大模型的微调(Fine Tuning) ，这也是今天这篇文章的主题。 8 | 9 | 今天这篇文章，我们抛开复杂的技术细节，用最通俗、直观的语言，为大家揭开大模型微调技术的神秘面纱。 10 | 11 | ## 什么是大模型 12 | 13 | 开始之前，为了方便大家理解，我们先对大模型做一个直观的抽象。 14 | 15 | 本质上，现在的大模型要解决的问题，就是一个序列数据转换的问题： 16 | 17 | 输入序列 X = [x1, x2, ..., xm]， 输出序列Y = [y1, y2, …, yn]，X和Y之间的关系是：Y = WX。 18 | 19 | 我们所说的“大模型”这个词：“大”是指用于训练模型的参数非常多，多达千亿、万亿；而“模型”指的就是上述公式中的矩阵W。 20 | 21 | 在这里，矩阵W就是通过机器学习，得出的用来将X序列，转换成Y序列的权重参数组成的矩阵。 22 | 23 | 需要特别说明：这里为了方便理解，做了大量的简化。在实际的模型中，会有多个用于不同目的的权重参数矩阵，也还有一些其它参数。 24 | 25 | ## 为什么要对大模型进行微调 26 | 27 | 通常，要对大模型进行微调，有以下一些原因： 28 | 29 | 第一个原因是，因为大模型的参数量非常大，训练成本非常高，每家公司都去从头训练一个自己的大模型，这个事情的性价比非常低； 30 | 31 | 第二个原因是，Prompt Engineering的方式是一种相对来说容易上手的使用大模型的方式，但是它的缺点也非常明显。因为通常大模型的实现原理，都会对输入序列的长度有限制，Prompt Engineering 的方式会把Prompt搞得很长。 32 | 33 | 越长的Prompt，大模型的推理成本越高，因为推理成本是跟Prompt长度的平方正向相关的。 34 | 35 | 另外，Prompt太长会因超过限制而被截断，进而导致大模型的输出质量打折口，这也是一个非常严重的问题。 36 | 37 | 对于个人使用者而言，如果是解决自己日常生活、工作中的一些问题，直接用Prompt Engineering的方式，通常问题不大。 38 | 39 | 但对于对外提供服务的企业来说，要想在自己的服务中接入大模型的能力，推理成本是不得不要考虑的一个因素，微调相对来说就是一个更优的方案。 40 | 41 | 第三个原因是，Prompt Engineering的效果达不到要求，企业又有比较好的自有数据，能够通过自有数据，更好的提升大模型在特定领域的能力。这时候微调就非常适用。 42 | 43 | 第四个原因是，要在个性化的服务中使用大模型的能力，这时候针对每个用户的数据，训练一个轻量级的微调模型，就是一个不错的方案。 44 | 45 | 第五个原因是，数据安全的问题。如果数据是不能传递给第三方大模型服务的，那么搭建自己的大模型就非常必要。通常这些开源的大模型都是需要用自有数据进行微调，才能够满足业务的需求，这时候也需要对大模型进行微调。 46 | 47 | ## 如何对大模型进行微调 48 | 49 | 从参数规模的角度，大模型的微调分成两条技术路线： 50 | 51 | 一条是对全量的参数，进行全量的训练，这条路径叫全量微调FFT(Full Fine Tuning)。 52 | 53 | 一条是只对部分的参数进行训练，这条路径叫PEFT(Parameter-Efficient Fine Tuning)。 54 | 55 | FFT的原理，就是用特定的数据，对大模型进行训练，将W变成W`，W`相比W ，最大的优点就是上述特定数据领域的表现会好很多。 56 | 57 | 但FFT也会带来一些问题，影响比较大的问题，主要有以下两个： 58 | 59 | 一个是训练的成本会比较高，因为微调的参数量跟预训练的是一样的多的； 60 | 61 | 一个是叫灾难性遗忘(Catastrophic Forgetting)，用特定训练数据去微调可能会把这个领域的表现变好，但也可能会把原来表现好的别的领域的能力变差。 62 | 63 | PEFT主要想解决的问题，就是FFT存在的上述两个问题，PEFT也是目前比较主流的微调方案。 64 | 65 | 从训练数据的来源、以及训练的方法的角度，大模型的微调有以下几条技术路线： 66 | 67 | 一个是监督式微调SFT(Supervised Fine Tuning) ，这个方案主要是用人工标注的数据，用传统机器学习中监督学习的方法，对大模型进行微调； 68 | 69 | 一个是基于人类反馈的强化学习微调RLHF(Reinforcement Learning with Human Feedback) ，这个方案的主要特点是把人类的反馈，通过强化学习的方式，引入到对大模型的微调中去，让大模型生成的结果，更加符合人类的一些期望； 70 | 71 | 还有一个是基于AI反馈的强化学习微调RLAIF(Reinforcement Learning with AI Feedback) ，这个原理大致跟RLHF类似，但是反馈的来源是AI。这里是想解决反馈系统的效率问题，因为收集人类反馈，相对来说成本会比较高、效率比较低。 72 | 73 | 不同的分类角度，只是侧重点不一样，对同一个大模型的微调，也不局限于某一个方案，可以多个方案一起。 74 | 75 | 微调的最终目的，是能够在可控成本的前提下，尽可能地提升大模型在特定领域的能力。 76 | 77 | ## 一些比较流行的PEFT方案 78 | 79 | 从成本和效果的角度综合考虑，PEFT是目前业界比较流行的微调方案。接下来介绍几种比较流行的PEFT微调方案。 80 | 81 | ### Prompt Tuning 82 | 83 | Prompt Tuning的出发点，是基座模型(Foundation Model)的参数不变，为每个特定任务，训练一个少量参数的小模型，在具体执行特定任务的时候按需调用。 84 | 85 | Prompt Tuning的基本原理是在输入序列X之前，增加一些特定长度的特殊Token，以增大生成期望序列的概率。 86 | 87 | 具体来说，就是将X = [x1, x2, ..., xm]变成，X` = [x`1, x`2, ..., x`k; x1, x2, ..., xm], Y = WX`。 88 | 89 | 根据我们在《揭密Transformer：大模型背后的硬核技术》一文中介绍的大模型背后的Transformer模型，Prompt Tuning是发生在Embedding这个环节的。 90 | 91 | 如果将大模型比做一个函数：Y=f(X)，那么Prompt Tuning就是在保证函数本身不变的前提下，在X前面加上了一些特定的内容，而这些内容可以影响X生成期望中Y的概率。 92 | 93 | Prompt Tuning的具体细节，可以参见：The Power of Scale for Parameter-Efficient Prompt Tuning[1]。 94 | 95 | ### Prefix Tuning 96 | 97 | Prefix Tuning的灵感来源是，基于Prompt Engineering的实践表明，在不改变大模型的前提下，在Prompt上下文中添加适当的条件，可以引导大模型有更加出色的表现。 98 | 99 | Prefix Tuning的出发点，跟Prompt Tuning的是类似的，只不过它们的具体实现上有一些差异。 100 | 101 | Prompt Tuning是在Embedding环节，往输入序列X前面加特定的Token。 102 | 103 | 而Prefix Tuning是在Transformer的Encoder和Decoder的网络中都加了一些特定的前缀。 104 | 105 | 具体来说，就是将Y=WX中的W，变成W` = [Wp; W]，Y=W`X。 106 | 107 | Prefix Tuning也保证了基座模型本身是没有变的，只是在推理的过程中，按需要在W前面拼接一些参数。 108 | 109 | Prefix Tuning的具体细节，可以参见：Prefix-Tuning: Optimizing Continuous Prompts for Generation[2]。 110 | 111 | ### LoRA 112 | 113 | LoRA是跟Prompt Tuning和Prefix Tuning完全不相同的另一条技术路线。 114 | 115 | LoRA背后有一个假设：我们现在看到的这些大语言模型，它们都是被过度参数化的。而过度参数化的大模型背后，都有一个低维的本质模型。 116 | 117 | 通俗讲人话：大模型参数很多，但并不是所有的参数都是发挥同样作用的；大模型中有其中一部分参数，是非常重要的，是影响大模型生成结果的关键参数，这部分关键参数就是上面提到的低维的本质模型。 118 | 119 | LoRA的基本思路，包括以下几步： 120 | 121 | 首先, 要适配特定的下游任务，要训练一个特定的模型，将Y=WX变成Y=(W+∆W)X，这里面∆W主是我们要微调得到的结果； 122 | 123 | 其次，将∆W进行低维分解∆W=AB (∆W为m * n维，A为m * r维，B为r * n维，r就是上述假设中的低维)； 124 | 125 | 接下来，用特定的训练数据，训练出A和B即可得到∆W，在推理的过程中直接将∆W加到W上去，再没有额外的成本。 126 | 127 | 另外，如果要用LoRA适配不同的场景，切换也非常方便，做简单的矩阵加法即可：(W + ∆W) - ∆W + ∆W`。 128 | 129 | 关于LoRA的具体细节，可以参见LoRA: Low-Rank Adaptation of Large Language Models[3]。 130 | 131 | ### QLoRA 132 | 133 | LoRA 效果已经非常好了，可以媲美全量微调的效果了，那为什么还要有个QLoRA呢？ 134 | 135 | 这里先简单介绍一下，量化（Quantization）。 136 | 137 | 量化，是一种在保证模型效果基本不降低的前提下，通过降低参数的精度，来减少模型对于计算资源的需求的方法。 138 | 139 | 量化的核心目标是降成本，降训练成本，特别是降后期的推理成本。 140 | 141 | QLoRA就是量化版的LoRA，它是在LoRA的基础上，进行了进一步的量化，将原本用16bit表示的参数，降为用4bit来表示，可以在保证模型效果的同时，极大地降低成本。 142 | 143 | 论文中举的例子，65B的LLaMA 的微调要780GB的GPU内存；而用了QLoRA之后，只需要48GB。效果相当惊人！ 144 | 145 | 关于QLoRA的具体细节，可以参见：QLoRA: Efficient Finetuning of Quantized LLMs[4]。 146 | 147 | PEFT 的微调方法，还有很多种，限于篇幅原因，不再这里一一介绍。感兴趣的朋友，可以阅读这篇论文：Scaling Down to Scale Up: A Guide to Parameter-Efficient Fine-Tuning[5]。 148 | 149 | Enjoy! 150 | -------------------------------------------------------------------------------- /aigc/basic/gelu.md: -------------------------------------------------------------------------------- 1 | # gelu 2 | 3 | 不管其他领域的鄙视链，在激活函数领域，大家公式的鄙视链应该是：Elus > Relu > Sigmoid ，这些激活函数都有自身的缺陷， sigmoid容易饱和，Elus 与 Relu 缺乏随机因素。 4 | 5 | 在神经网络的建模过程中，模型很重要的性质就是非线性，同时为了模型泛化能力，需要加入随机正则，例如 dropout (随机置一些输出为0,其实也是一种变相的随机非线性激活)， 而随机正则与非线性激活是分开的两个事情， 而其实模型的输入是由非线性激活与随机正则两者共同决定的。 6 | 7 | GELUs (Gaussian Error Linerar Units) 正是在激活中引入了随机正则的思想，是一种对神经元输入的概率描述，直观上更符合自然的认识，同时实验效果要比 Relus 与 ELUs 都要好。 8 | 9 | GELUs 其实是 dropout、zoneout、Relus 的综合，GELUs 对于输入乘以一个 0,1 组成的 mask，而该 mask 的生成则是概率随机的依赖于输入。假设输入为 X, mask 为 m，则 m 服从一个伯努利分布(Φ(x), Φ(x) = P(X <= x) , X 服从标准正太分布)，这么选择是因为神经元的输入趋向于正太分布，这么设定使得当输入 x 减小的时候，输入会有一个更高的概率被 dropout 掉，这样的激活变换就会随机依赖于输入了。 10 | 11 | > 伯努利分布又名两点分布或者 0-1 分布。 12 | 13 | ![gelu](pics/gelu.png) 14 | 15 | 16 | -------------------------------------------------------------------------------- /aigc/basic/gpt-1_2_3.md: -------------------------------------------------------------------------------- 1 | ![](pics/gpt-1_2_3.png) 2 | ![](pics/gpt-1_2_3_a.png) 3 | -------------------------------------------------------------------------------- /aigc/basic/lora.md: -------------------------------------------------------------------------------- 1 | # 大模型低秩适配器LoRA 2 | > refer to: https://zhuanlan.zhihu.com/p/646831196 3 | > refer to: https://zhuanlan.zhihu.com/p/618073170 4 | 5 | ## 全参数微调 6 | 7 | 我们知道，微调的含义，就是把已经训练好的模型（pretrained model）拿来，给它吃特定的下游任务数据，使得模型在预训练权重上继续训练，直至满足下游任务性能标准。预训练模型就像一个特征提取器，能够基于先前训练数据中学到的经验，为我们提取有效的特征，大大提升下游任务的训练效果和收敛速度。 8 | 9 | **全量微调**指的是，在下游任务的训练中，对预训练模型的每一个参数都做更新。例如图中，给出了Transformer的Q/K/V矩阵的全量微调示例，对每个矩阵来说，在微调时，其`d*d`个参数，都必须参与更新。 10 | 11 | ![fine_tuning](pics/fine_tuning.png) 12 | 13 | 全量微调的显著缺点是，训练代价昂贵。例如GPT3的参数量有175B，我等单卡贵族只能望而却步，更不要提在微调中发现有bug时的覆水难收。同时，由于模型在预训练阶段已经吃了足够多的数据，收获了足够的经验，**因此我只要想办法给模型增加一个额外知识模块，让这个小模块去适配我的下游任务，模型主体保持不变（freeze）即可。** 14 | 15 | 那这样的知识小模块，具体要怎么添加呢？ 16 | 17 | ## Adapter Tuning 与 Prefix Tuning 18 | 19 | 我们来看在LoRA出现前，两种主流的局部微调办法：Adapter Tuning与Prefix Tuning。这也是LoRA的原始论文中，重点比对的两种微调方式。 20 | 21 | ### Adapter Tuning 22 | 23 | ![adapter](pics/adapter.png) 24 | 25 | Adapter Tuning的方法有很多种，这里我们举出Houlsby et al. ,2019提出的方法，这也是LoRA论文中提及这项技术时所引用的第一篇文章。 26 | 27 | 图例中的左边是一层Transformer Layer结构，其中的Adapter就是我们说的“额外知识模块”；右边是Adatper的具体结构。**在微调时，除了Adapter的部分，其余的参数都是被冻住的（freeze）**，这样我们就能有效降低训练的代价。Adapter的内部架构不是本文所述的重点，这里我们就不再介绍了。 28 | 29 | 但这样的设计架构存在一个**显著劣势：添加了Adapter后，模型整体的层数变深，会增加训练速度和推理速度**，原因是： 30 | 31 | - 需要耗费额外的运算量在Adapter上 32 | - 当我们采用并行训练时（例如Transformer架构常用的张量模型并行），Adapter层会产生额外的通讯量，增加通讯时间 33 | 34 | ### Prefix Tuning 35 | 36 | Prefix Tuning的方法也有很多种，这里我们选取Li&Liang,2021这一篇进行简述。**在这篇中，作者通过对输入数据增加前缀（prefix）来做微调。当然，prefix也可以不止加载输入层，还可以加在Transformer Layer输出的中间层，感兴趣的朋友可以查找论文自行研究。** 37 | 38 | 如图所示，对于GPT这样的生成式模型，在输入序列的最前面加入prefix token，图例中加入2个prefix token，在实际应用中，prefix token的个数是个超参，可以根据模型实际微调效果进行调整。对于BART这样的Encoder-Decoder架构模型，则在x和y的前面同时添加prefix token。在后续微调中，我们只需要冻住模型其余部分，单独训练prefix token相关的参数即可，每个下游任务都可以单独训练一套prefix token。 39 | 40 | ![prefix](pics/prefix.png) 41 | 42 | 那么prefix的含义是什么呢？prefix的作用是引导模型提取x相关的信息，进而更好地生成y。例如，我们要做一个summarization的任务，那么经过微调后，prefix就能领悟到当前要做的是个“总结形式”的任务，然后引导模型去x中提炼关键信息；如果我们要做一个情感分类的任务，prefix就能引导模型去提炼出x中和情感相关的语义信息，以此类推。这样的解释可能不那么严谨，但大家可以大致体会一下prefix的作用。 43 | 44 | Prefix Tuning虽然看起来方便，但也存在以下两个显著劣势: 45 | 46 | - 较难训练，且模型的效果并不严格随prefix参数量的增加而上升，这点在原始论文中也有指出 47 | - 会使得输入层有效信息长度减少。为了节省计算量和显存，我们一般会固定输入数据长度。增加了prefix之后，留给原始文字数据的空间就少了，因此可能会降低原始文字中prompt的表达能力。 48 | 49 | ## 什么是LoRA 50 | 51 | 总结一下，**全参数微调太贵，Adapter Tuning存在训练和推理延迟，Prefix Tuning难训且会减少原始训练数据中的有效文字长度**，那是否有一种微调办法，能改善这些不足呢？ 52 | 53 | 在这样动机的驱动下，作者提出了**LoRA（Low-Rank Adaptation，低秩适配器）这样一种微调方法**。我们先抛开对“低秩”、“适配器”这样抽象词语的解释，我们先来看LoRA长什么样，要怎么用。在下一节中，我们再来详细解释“低秩”作用的原理。 54 | 55 | ### 问题描述 56 | 57 | ![00](pics/lora-00.png) 58 | 59 | ### LoRA整体架构 60 | 61 | ![lora-arch](pics/lora-arch.png) 62 | 63 | **图中左侧表示“全参数finetune”的场景**。我们将参数分成了两个部分： 64 | 65 | ![full-ft](pics/full-fine-tuning.png) 66 | 67 | 之所以这么拆分，是因为**全参数finetune可以理解成“冻住的预训练权重” + “微调过程中产生的权重更新量”。** 68 | 69 | ![01](pics/lora-01.png) 70 | 71 | ![2](pics/lora-2.png) 72 | 73 | 经过这样一番拆分，使得微调参数量从`d*d`降低至`2*r*d`，同时不改变输出数据的维度。 74 | 75 | 需要注意的是，这里对 A 采用高斯初始化，对 B 采用零初始化的目的是，让训练刚开始时 的值为0，这样不会给模型带来额外的噪声。那么你可能想问，那我对 A 做零初始化，对 B 做高斯初始化行不行呢？反正看起来只要让 初始化为0就行？ 76 | 77 | 针对这个问题，我在github issue上找到了LoRA一作的回答： 78 | 79 | ![1](pics/lora-1.png) 80 | 81 | 简单来说，当前作者还没有发现转换 A,B 初始化方式产生的显著区别，只要这两者中任意一者为0，另一者不为0即可。 82 | 83 | ### 训练 84 | 85 | ![02](pics/lora-02.png) 86 | 87 | ![03](pics/lora-03.png) 88 | 89 | ### 推理 90 | 91 | ![04](pics/lora-04.png) 92 | 93 | ![05](pics/lora-05.png) 94 | 95 | ### 低秩 alpha 和 r 的理解 96 | 97 | ![06](pics/lora-06.png) 98 | 99 | 我们前面说过，当 r 越小时，低秩矩阵所含的信息越精炼，但同时也可能越不全面。那么到底 r 要取多少才合适呢？ 100 | 101 | ![07](pics/lora-07.png) 102 | 103 | ![08](pics/lora-08.png) 104 | 105 | **得出的可能结论是，看起来 alpha 可以是 64，r 可以是 64、8 或者 4。具体要在模型的不同层和不同的应用场景去验证了。** 106 | -------------------------------------------------------------------------------- /aigc/basic/pics/Bottou-Afold.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Bottou-Afold.png -------------------------------------------------------------------------------- /aigc/basic/pics/Bottou-Atree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Bottou-Atree.png -------------------------------------------------------------------------------- /aigc/basic/pics/Bottou-WordSetup (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Bottou-WordSetup (1).png -------------------------------------------------------------------------------- /aigc/basic/pics/Bottou-WordSetup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Bottou-WordSetup.png -------------------------------------------------------------------------------- /aigc/basic/pics/Bottou-unfold.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Bottou-unfold.png -------------------------------------------------------------------------------- /aigc/basic/pics/Cho-TimePhrase-TSNE.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Cho-TimePhrase-TSNE.png -------------------------------------------------------------------------------- /aigc/basic/pics/Colbert-WordTable2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Colbert-WordTable2.png -------------------------------------------------------------------------------- /aigc/basic/pics/Convolutional_Neural_Network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Convolutional_Neural_Network.png -------------------------------------------------------------------------------- /aigc/basic/pics/Mikolov-AnalogyTable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Mikolov-AnalogyTable.png -------------------------------------------------------------------------------- /aigc/basic/pics/Mikolov-GenderVecs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Mikolov-GenderVecs.png -------------------------------------------------------------------------------- /aigc/basic/pics/Multilayer_perceptrons.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Multilayer_perceptrons.jpeg -------------------------------------------------------------------------------- /aigc/basic/pics/Neural_Network_general.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Neural_Network_general.png -------------------------------------------------------------------------------- /aigc/basic/pics/Recurrent_neural_networks.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Recurrent_neural_networks.png -------------------------------------------------------------------------------- /aigc/basic/pics/Single_layer_perceptron.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Single_layer_perceptron.png -------------------------------------------------------------------------------- /aigc/basic/pics/Socher-BillingualTSNE.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Socher-BillingualTSNE.png -------------------------------------------------------------------------------- /aigc/basic/pics/Socher-ImageClass-tSNE.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Socher-ImageClass-tSNE.png -------------------------------------------------------------------------------- /aigc/basic/pics/Socher-ImageClassManifold.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Socher-ImageClassManifold.png -------------------------------------------------------------------------------- /aigc/basic/pics/Socher-SentimentTree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Socher-SentimentTree.png -------------------------------------------------------------------------------- /aigc/basic/pics/Softmax_Function.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Softmax_Function.png -------------------------------------------------------------------------------- /aigc/basic/pics/Stochastic_gradient_descent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Stochastic_gradient_descent.png -------------------------------------------------------------------------------- /aigc/basic/pics/Turian-WordTSNE.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/Turian-WordTSNE.png -------------------------------------------------------------------------------- /aigc/basic/pics/activation-funcs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/activation-funcs.png -------------------------------------------------------------------------------- /aigc/basic/pics/activation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/activation.png -------------------------------------------------------------------------------- /aigc/basic/pics/adapter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/adapter.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_01.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_02.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_03.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_04.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_05.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_06.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_07.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_08.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_08.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_09.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_09.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_10.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_11.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_12.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_13.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_14.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_15.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_16.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_17.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_18.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_19.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_20.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_21.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_22.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_22.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_23.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_23.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_24.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_25.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_25.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_26.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_26.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_27.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_27.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_28.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_28.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_29.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_29.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_30.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_30.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_31.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_31.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_32.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_33.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_33.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_34.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_34.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_35.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_35.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_36.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_36.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_37.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_37.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_38.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_38.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_39.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_39.png -------------------------------------------------------------------------------- /aigc/basic/pics/bert_40.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/bert_40.png -------------------------------------------------------------------------------- /aigc/basic/pics/def.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/def.png -------------------------------------------------------------------------------- /aigc/basic/pics/diff_vectors.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/diff_vectors.png -------------------------------------------------------------------------------- /aigc/basic/pics/different-kinds-of-transfer-learning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/different-kinds-of-transfer-learning.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_1.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_10.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_11.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_12.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_2.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_3.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_4.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_5.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_6.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_7.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_8.png -------------------------------------------------------------------------------- /aigc/basic/pics/elmo_9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/elmo_9.png -------------------------------------------------------------------------------- /aigc/basic/pics/embedding_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/embedding_example.png -------------------------------------------------------------------------------- /aigc/basic/pics/embedding_parameterized.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/embedding_parameterized.png -------------------------------------------------------------------------------- /aigc/basic/pics/embedding_predict.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/embedding_predict.png -------------------------------------------------------------------------------- /aigc/basic/pics/exp.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/exp.jpeg -------------------------------------------------------------------------------- /aigc/basic/pics/fine_tuning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/fine_tuning.png -------------------------------------------------------------------------------- /aigc/basic/pics/flowchart-DeViSE.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/flowchart-DeViSE.png -------------------------------------------------------------------------------- /aigc/basic/pics/flowchart-TranfserLearning2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/flowchart-TranfserLearning2.png -------------------------------------------------------------------------------- /aigc/basic/pics/flowchart-bilingual.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/flowchart-bilingual.png -------------------------------------------------------------------------------- /aigc/basic/pics/full-fine-tuning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/full-fine-tuning.png -------------------------------------------------------------------------------- /aigc/basic/pics/gelu.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/gelu.png -------------------------------------------------------------------------------- /aigc/basic/pics/general_connection-residual_connection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/general_connection-residual_connection.png -------------------------------------------------------------------------------- /aigc/basic/pics/gpt-1_2_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/gpt-1_2_3.png -------------------------------------------------------------------------------- /aigc/basic/pics/gpt-1_2_3_a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/gpt-1_2_3_a.png -------------------------------------------------------------------------------- /aigc/basic/pics/instruction_tuning_with_pretrain–finetune_and_prompting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/instruction_tuning_with_pretrain–finetune_and_prompting.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-00.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-00.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-01.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-02.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-03.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-04.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-05.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-06.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-07.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-08.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-08.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-1.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-2.png -------------------------------------------------------------------------------- /aigc/basic/pics/lora-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/lora-arch.png -------------------------------------------------------------------------------- /aigc/basic/pics/mse.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/mse.png -------------------------------------------------------------------------------- /aigc/basic/pics/prefix.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/prefix.png -------------------------------------------------------------------------------- /aigc/basic/pics/relu-d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/relu-d.png -------------------------------------------------------------------------------- /aigc/basic/pics/relu-formula.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/relu-formula.png -------------------------------------------------------------------------------- /aigc/basic/pics/relu-pros-cons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/relu-pros-cons.png -------------------------------------------------------------------------------- /aigc/basic/pics/residual-connection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/residual-connection.png -------------------------------------------------------------------------------- /aigc/basic/pics/sigmoid-d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/sigmoid-d.png -------------------------------------------------------------------------------- /aigc/basic/pics/sigmoid-pros-cons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/sigmoid-pros-cons.png -------------------------------------------------------------------------------- /aigc/basic/pics/softmax-details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/softmax-details.png -------------------------------------------------------------------------------- /aigc/basic/pics/softmax-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/softmax-example.png -------------------------------------------------------------------------------- /aigc/basic/pics/softmax-formula-exp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/softmax-formula-exp.png -------------------------------------------------------------------------------- /aigc/basic/pics/softmax-formula.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/softmax-formula.png -------------------------------------------------------------------------------- /aigc/basic/pics/softmax-pros-cons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/softmax-pros-cons.png -------------------------------------------------------------------------------- /aigc/basic/pics/tanh-d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/tanh-d.png -------------------------------------------------------------------------------- /aigc/basic/pics/tanh-pros-cons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/tanh-pros-cons.png -------------------------------------------------------------------------------- /aigc/basic/pics/the-general-connections-and-the-residual-connections.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/the-general-connections-and-the-residual-connections.png -------------------------------------------------------------------------------- /aigc/basic/pics/word_embedding_mapping.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/pics/word_embedding_mapping.png -------------------------------------------------------------------------------- /aigc/basic/rank.md: -------------------------------------------------------------------------------- 1 | # 矩阵的秩 2 | 3 | 矩阵的`秩`，英文名称是 `rank`. 4 | 5 | 可以从向量组的角度来理解，矩阵的秩体现了矩阵包含信息的能力。 6 | 7 | 向量组的线性相关性：更多的向量！ 8 | 9 | 一般我们手头拥有的向量数量是有限的，但实际中肯定有无限多个向量。通过线性组合，我们可以得到更多其他的向量。 10 | 11 | 线性组合本身的定义很简单： 12 | - 线性就是向量前面乘上一个系数，将向量缩放； 13 | - 组合就是将他们相加，遵循向量加法原则。 14 | 15 | 比如，当我们拥有两个不在一条直线上的二维向量，通过线性组合，我们就可以得到平面上任意一个二维向量。 16 | 17 | 换一种说法，只要拥有这样不在一条直线上的向量，我们就拥有了整个二维平面上的向量。或者说这两个向量可以张开为一个平面（二维空间）。 18 | 19 | 一旦两个向量在同一直线上，我们就只能拥有方向和这一直线相同的所有向量。或者说这两个向量可以张开为一条直线（一维空间）。 20 | 21 | 两个不在一条直线上的三维向量也能张开为一个平面，下面是在三维空间中的平面。 22 | 23 | 事实上，两个向量“不在一条直线上”这一条件就是指这两个二维向量“线性无关”。与线性无关相对的一个词，即“线性相关”，在同一直线上的向量线性相关。怎么严格定义线性相关呢？我的理解就是如果某个向量能用其它向量的线性组合所表示，那么他们就是线性相关的。 24 | 25 | **当向量组中至少有一个向量可以由其余向量的线性组合表示，则向量组线性相关。**之前两个向量在一条直线上的情况里，其中一个向量就能被另一个向量线性表示（乘一个系数）。 26 | 27 | 相对地，线性无关即向量组中，任何一个向量都不能被其他向量线性表示，每个向量都是独特的、不可替代的。 28 | 29 | 此时，**当且仅当所有系数k都为0时，线性无关的向量组才能线性表示零向量。**两个不在同一直线的向量，就是这种情况。 30 | 31 | 这里还有一个非常显而易见的结论，我们可以在向量组内进行线性组合，组合出来的新向量依旧在原向量组所能表示的空间内，不会跳出这个空间。 32 | 33 | 也就是说，向量之间进行线性组合处理后，向量组对空间的“表述能力”保持不变。 34 | 35 | ## 向量组的秩&矩阵的秩 36 | 37 | > 我直接把向量组当作矩阵，矩阵当作向量组啦 38 | 39 | 先解决第一个问题，即如何得到向量组中，放在一起能保证线性无关的向量的最大个数。其实我们就是把这个最大个数叫作“秩”，一般记作R。 40 | 41 | 秩？从来没见过的字吼，但我们得习惯这么称呼他，记住这就是一个数。从定义来看向量组里同时线性无关的向量最多有R个，向量组最多能张开为R维空间。 42 | 43 | 从另一个角度看，我们去掉了线性相关的向量，即淘汰了”冗余“信息，因为这些向量能被别的向量线性表示，最后线性无关的向量数量就是秩，所以秩在一定程度上体现了矩阵实际包含信息的能力。 44 | 45 | 可以理解为，秩越大，矩阵的表达能力越强，信息量也越大。 46 | 47 | ## 如何得到秩 48 | 49 | 如何得到秩？我们可不可以不断地进行线性组合，找到那几个能被其他向量表示的向量，去掉他们，剩下的向量就能保证线性无关了。这个逻辑很简单，但是实际运算，想想都觉得麻烦，还得一个一个地去找。 50 | 51 | 不断进行线性组合这一思想是正确的，但肯定不能盲目地、一个一个地尝试。书本上告诉我们的方法，就能又快又准得到矩阵的秩： 52 | - 先对矩阵做初等行变换将其化为阶梯形矩阵（初等变换不改变矩阵的秩）； 53 | - 确定阶梯形矩阵中非零行的行数。 54 | 55 | 将矩阵变为阶梯形的过程，就是在尝试找出能被其他行向量线性表示的行向量，最后全为0的行向量就是能被被的向量线性表示的向量。 56 | 57 | 剩下的不全为0的行向量，不能被其他行向量线性表示，所以这些向量就是极大线性无关组，非零行的行数也就是“秩”了。 58 | 59 | 肯定有人和我一样，会想既然能处理行向量，那么能不能通过处理列向量来得到秩呢？即计算列向量的阶梯矩阵，得到的结果会和行向量的一样吗？ 60 | 61 | 非常神奇的是，结果是一样的。**矩阵的秩是唯一的，无论我们以列向量的角度，还是行向量的角度去看待它。** 62 | -------------------------------------------------------------------------------- /aigc/basic/relu.md: -------------------------------------------------------------------------------- 1 | # relu 2 | 3 | **relu, rectified linear unit, is primarily used in the hidden layers of neural networks to ensure non-linearity.** The function caps all outputs to zero and above. Outputs below zero are returned as zero, while numbers above zero are returned as they are. This ensures that there are no negative numbers in the network. 4 | 5 | ![relu-formula](pics/relu-formula.png) 6 | 7 | ![def](pics/def.png) 8 | 9 | ## relu 分析 10 | 11 | ![d](pics/relu-d.png) 12 | 13 | 从上图可知，**ReLU 的有效导数是常数1，解决了深层网络中出现的梯度消失问题，也就使得深层网络可训练。同时 ReLU 又是非线性函数，所谓非线性，就是一阶导数不为常数；对 ReLU 求导，在输入值分别为正和为负的情况下，导数是不同的，即 ReLU 的导数不是常数，所以 ReLU 是非线性的（只是不同于 Sigmoid 和 tanh，relu 的非线性不是光滑的）。** 14 | 15 | **ReLU 在 x>0 下，导数为常数1的特点：** 16 | 17 | 导数为常数1的好处就是在“链式反应”中不会出现梯度消失，但梯度下降的强度就完全取决于权值的乘积，这样就可能会出现梯度爆炸问题。解决这类问题：一是控制权值，让它们在（0，1）范围内；二是做梯度裁剪，控制梯度下降强度，如 ReLU(x)=min(6, max(0,x))。 18 | 19 | **ReLU 在 x<0 下，输出置为0的特点：** 20 | 21 | 描述该特征前，需要明确深度学习的目标：深度学习是根据大批量样本数据，从错综复杂的数据关系中，找到关键信息（关键特征）。换句话说，就是把密集矩阵转化为稀疏矩阵，保留数据的关键信息，去除噪音，这样的模型就有了鲁棒性。ReLU 将 x<0 的输出置为0，就是一个去噪音，稀疏矩阵的过程。而且在训练过程中，这种稀疏性是动态调节的，网络会自动调整稀疏比例，保证矩阵有最优的有效特征。**ReLu 会使一部分神经元的输出为0，这样就造成了网络的稀疏性，同时减少了参数的相互依存关系，缓解了过拟合问题的发生。** 22 | 23 | **正因为有了这单侧抑制，才使得神经网络中的神经元也具有了稀疏激活性。尤其体现在深度神经网络模型(如 CNN )中，当模型增加N层之后，理论上ReLU神经元的激活率将降低2的N次方倍。** 24 | 25 | 那么问题来了：**这种稀疏激活性有何作用？** 换句话说，我们为什么需要让神经元稀疏？不妨举栗子来说明。当看名侦探柯南的时候，我们可以根据故事情节进行思考和推理，这时用到的是我们的大脑左半球；而当看蒙面唱将时，我们可以跟着歌手一起哼唱，这时用到的则是我们的右半球。左半球侧重理性思维，而右半球侧重感性思维。也就是说，当我们在进行运算或者欣赏时，都会有一部分神经元处于激活或是抑制状态，可以说是各司其职。再比如，生病了去医院看病，检查报告里面上百项指标，但跟病情相关的通常只有那么几个。与之类似，当训练一个深度分类模型的时候，和目标相关的特征往往也就那么几个，**因此通过ReLU实现稀疏后的模型能够更好地挖掘相关特征，拟合训练数据。** 26 | 27 | 但是 ReLU 强制将 x<0 部分的输出置为0（置为0就是屏蔽该特征），可能会导致模型无法学习到有效特征，所以如果学习率设置的太大，就可能会导致网络的大部分神经元处于‘dead’状态，所以使用 ReLU 的网络，学习率不能设置太大。**当然，如果你设置了一个合适的较小的 learning rate，这个问题发生的情况其实也不会太频繁。** 28 | 29 | **ReLU 作为激活函数的特点：** 30 | 31 | - 相比 Sigmoid 和 tanh，ReLU 摒弃了复杂的计算，提高了运算速度。 32 | - 解决了梯度消失问题，收敛速度快于 Sigmoid 和 tanh 函数，但要防范 ReLU 的梯度爆炸 33 | - 容易得到更好的模型，但也要防止训练中出现模型‘Dead’情况。 34 | 35 | ## pros and cons 36 | 37 | ![pros-cons](pics/relu-pros-cons.png) 38 | -------------------------------------------------------------------------------- /aigc/basic/residual_connection.md: -------------------------------------------------------------------------------- 1 | # Residual Connection 2 | 3 | ![Residual Block](pics/residual-connection.png) 4 | 5 | A Residual Block: 6 | 7 | - The intuition behind a network with residual blocks is that each layer is fed to the next layer of the network and also directly to the next layers skipping between a few layers in between. 8 | - Residual blocks allow you to train much deeper neural networks. 9 | - The connection(gray arrow) is called **skip connection** or **shortcut connection** as it is bypassing one or more layers in between. 10 | - It is also called **identity connection** as we can learn an identity function from it. 11 | 12 | ![vs](pics/the-general-connections-and-the-residual-connections.png) 13 | ![vs](pics/general_connection-residual_connection.png) 14 | 15 | The comparison between the general connections and the residual connections used in ResNet. 16 | 1. describes how the input data x is passed into the weight layers in general CNN models with no residual connections. 17 | 2. shows how x is passed to both the weight layers and the residual connections in ResNet. 18 | -------------------------------------------------------------------------------- /aigc/basic/sigmoid.md: -------------------------------------------------------------------------------- 1 | # sigmoid 2 | 3 | ![](pics/sigmoid-d.png) 4 | 5 | 缺点： 6 | 7 | - 激活函数计算量大（在正向传播和反向传播中都包含幂运算和除法）； 8 | 反向传播求误差梯度时，求导涉及除法； 9 | - Sigmoid导数取值范围是[0, 0.25]，由于神经网络反向传播时的“链式反应”，很容易就会出现梯度消失的情况。例如对于一个10层的网络， 根据 `0.25~10 = 0.000000954`，第10层的误差相对第一层卷积的参数 W1 的梯度将是一个非常小的值，这就是所谓的“梯度消失”。 10 | - Sigmoid的输出不是0均值（即 zero-centered）；这会导致后一层的神经元将得到上一层输出的非0均值的信号作为输入，随着网络的加深，会改变数据的原始分布。 11 | 12 | ## pros and cons 13 | 14 | ![pros-cons](pics/sigmoid-pros-cons.png) 15 | -------------------------------------------------------------------------------- /aigc/basic/softmax.md: -------------------------------------------------------------------------------- 1 | # softmax 2 | 3 | **softmax 函数，归一化指数函数。** 利用 softmax 函数可以将我们的输出映射成 [0,1] 区间的权重/概率。 4 | 5 | 假设我们有一个向量 `X`，`Xi` 表示向量 `X` 的第 `i` 个元素，那么这个元素的 `softmax` 值计算公式如下： 6 | 7 | ![formula](pics/softmax-formula.png) 8 | 9 | 或者 10 | 11 | ![formula-exp](pics/softmax-formula-exp.png) 12 | 13 | ![function](pics/Softmax_Function.png) 14 | 15 | 更形象的如下图表示： 16 | 17 | ![example](pics/softmax-example.png) 18 | 19 | 上述示例中，原来输出是 `3,1,-3` 通过 softmax 函数一作用，就映射成为 [0,1] 的值，而这些值的累和为 1（满足概率的性质），那么我们就可以将它理解成概率，在最后选取输出结点的时候，我们就可以选取概率最大（也就是值对应最大的）结点，作为我们的预测目标！ 20 | 21 | **softmax 函数满足概率的两个性质：** 22 | **1. 预测的概率为非负数；** 23 | **2. 各种预测结果概率之和为1。** 24 | 25 | 所以 softmax 做了两件事情： 26 | 27 | **1. softmax 函数分子：将预测结果转化为非负数** 28 | 29 | 我们知道指数函数的值域取值区间为非负数，同时保持了原有数值间的大小关系，比如 `a > b`，那么 `exp(a) > exp(b) > 0`： 30 | 31 | ![exp](pics/exp.jpeg) 32 | 33 | **softmax 第一步将模型的预测结果转化到指数函数上，这样保证了概率的非负性。** 34 | 35 | **2. softmax 函数分母：各种预测结果概率之和为1** 36 | 37 | **为了确保各个预测结果的概率之和为1，我们只需要将转化后的结果进行归一化处理。方法就是将转化后的结果除以所有转化后结果之和，可以理解为转化后结果占总数的百分比。** 这样就得到近似的概率。 38 | 39 | 斯坦福大学课程中 softmax 函数的展开解释如下： 40 | 41 | ![details](pics/softmax-details.png) 42 | 43 | **pros and cons：** 44 | 45 | ![pros-cons](pics/softmax-pros-cons.png) 46 | -------------------------------------------------------------------------------- /aigc/basic/tanh.md: -------------------------------------------------------------------------------- 1 | # tanh 2 | 3 | ![tanh](pics/tanh-d.png) 4 | 5 | tanh 为双曲正切函数，其英文读作 Hyperbolic Tangent。tanh 和 sigmoid 相似，都属于饱和激活函数，区别在于输出值范围由 `(0,1)` 变为了 `(-1,1)`，可以把 tanh 函数看做是 sigmoid 向下平移和拉伸后的结果。 6 | 7 | 相比 Sigmoid 函数， 8 | 9 | - tanh 的输出范围时(-1, 1)，解决了 Sigmoid 函数的不是zero-centered 输出问题； 10 | - 幂运算的问题仍然存在； 11 | - tanh导数范围在(0, 1)之间，相比 sigmoid的(0, 0.25)，梯度消失（gradient vanishing）问题会得到缓解，但仍然还会存在。 12 | 13 | ## pros and cons 14 | 15 | ![pros-cons](pics/tanh-pros-cons.png) 16 | -------------------------------------------------------------------------------- /aigc/basic/vae/AI艺术的背后：详解文本生成图像模型 - 知乎.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/vae/AI艺术的背后：详解文本生成图像模型 - 知乎.pdf -------------------------------------------------------------------------------- /aigc/basic/vae/EM算法.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/vae/EM算法.pdf -------------------------------------------------------------------------------- /aigc/basic/vae/Understanding_VAE.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/vae/Understanding_VAE.pdf -------------------------------------------------------------------------------- /aigc/basic/vae/VAE.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/vae/VAE.pdf -------------------------------------------------------------------------------- /aigc/basic/vae/VAE_简单推导.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/vae/VAE_简单推导.pdf -------------------------------------------------------------------------------- /aigc/basic/vae/VAE变分自编码器公式推导.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/basic/vae/VAE变分自编码器公式推导.pdf -------------------------------------------------------------------------------- /aigc/pics/autonomous_AI_mechanism.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/autonomous_AI_mechanism.png -------------------------------------------------------------------------------- /aigc/pics/autopgt_logic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/autopgt_logic.png -------------------------------------------------------------------------------- /aigc/pics/bidirectional-RNN.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/bidirectional-RNN.png -------------------------------------------------------------------------------- /aigc/pics/chuantong.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/chuantong.png.webp -------------------------------------------------------------------------------- /aigc/pics/command_prompt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/command_prompt.png -------------------------------------------------------------------------------- /aigc/pics/embedding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/embedding.png -------------------------------------------------------------------------------- /aigc/pics/fenci.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/fenci.gif -------------------------------------------------------------------------------- /aigc/pics/gpt-4_task_memory.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/gpt-4_task_memory.webp -------------------------------------------------------------------------------- /aigc/pics/input-5.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/input-5.gif -------------------------------------------------------------------------------- /aigc/pics/input-output.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/input-output.png.webp -------------------------------------------------------------------------------- /aigc/pics/input-time.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/input-time.gif -------------------------------------------------------------------------------- /aigc/pics/input-what.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/input-what.gif -------------------------------------------------------------------------------- /aigc/pics/kantu.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/kantu.png.webp -------------------------------------------------------------------------------- /aigc/pics/llm-invoke-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm-invoke-example.png -------------------------------------------------------------------------------- /aigc/pics/llm_CommaSeparatedListOutputParser.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_CommaSeparatedListOutputParser.png -------------------------------------------------------------------------------- /aigc/pics/llm_DatetimeOutputParser.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_DatetimeOutputParser.png -------------------------------------------------------------------------------- /aigc/pics/llm_DuckDuckGo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_DuckDuckGo.png -------------------------------------------------------------------------------- /aigc/pics/llm_PyPDFLoader.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_PyPDFLoader.png -------------------------------------------------------------------------------- /aigc/pics/llm_ShellTool.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_ShellTool.png -------------------------------------------------------------------------------- /aigc/pics/llm_ShellTool2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_ShellTool2.png -------------------------------------------------------------------------------- /aigc/pics/llm_SimpleJsonOutputParser.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_SimpleJsonOutputParser.png -------------------------------------------------------------------------------- /aigc/pics/llm_agent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_agent.png -------------------------------------------------------------------------------- /aigc/pics/llm_chain.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_chain.gif -------------------------------------------------------------------------------- /aigc/pics/llm_chain_legacy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_chain_legacy.png -------------------------------------------------------------------------------- /aigc/pics/llm_chatmessage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_chatmessage.png -------------------------------------------------------------------------------- /aigc/pics/llm_pdf_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_pdf_example.png -------------------------------------------------------------------------------- /aigc/pics/llm_pdfretriever.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_pdfretriever.png -------------------------------------------------------------------------------- /aigc/pics/llm_pdfretriever2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_pdfretriever2.png -------------------------------------------------------------------------------- /aigc/pics/llm_pydantic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_pydantic.png -------------------------------------------------------------------------------- /aigc/pics/llm_stream_example.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/llm_stream_example.gif -------------------------------------------------------------------------------- /aigc/pics/lstm-gru.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/lstm-gru.png.webp -------------------------------------------------------------------------------- /aigc/pics/memory_history.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/memory_history.png -------------------------------------------------------------------------------- /aigc/pics/models-price.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/models-price.png -------------------------------------------------------------------------------- /aigc/pics/output.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/output.gif -------------------------------------------------------------------------------- /aigc/pics/pinglun-hzd.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/pinglun-hzd.png.webp -------------------------------------------------------------------------------- /aigc/pics/pinglun.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/pinglun.png.webp -------------------------------------------------------------------------------- /aigc/pics/quedian.jpg.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/quedian.jpg.webp -------------------------------------------------------------------------------- /aigc/pics/rnn-1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn-1.gif -------------------------------------------------------------------------------- /aigc/pics/rnn-lstm.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn-lstm.png.webp -------------------------------------------------------------------------------- /aigc/pics/rnn.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn.webp -------------------------------------------------------------------------------- /aigc/pics/rnn_base.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn_base.jpeg -------------------------------------------------------------------------------- /aigc/pics/rnn_detail.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn_detail.png -------------------------------------------------------------------------------- /aigc/pics/rnn_func.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn_func.png -------------------------------------------------------------------------------- /aigc/pics/rnn_simple.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn_simple.png -------------------------------------------------------------------------------- /aigc/pics/rnn_t.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/rnn_t.webp -------------------------------------------------------------------------------- /aigc/pics/stacked-bidirectional-RNN.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/stacked-bidirectional-RNN.png -------------------------------------------------------------------------------- /aigc/pics/text2vector.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/text2vector.gif -------------------------------------------------------------------------------- /aigc/pics/tiankong.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/tiankong.png.webp -------------------------------------------------------------------------------- /aigc/pics/yingyong.png.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/pics/yingyong.png.webp -------------------------------------------------------------------------------- /aigc/rnn1.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [一文搞懂RNN（循环神经网络）基础篇](#一文搞懂rnn循环神经网络基础篇) 4 | - [神经网络基础](#神经网络基础) 5 | - [为什么需要RNN（循环神经网络）](#为什么需要rnn循环神经网络) 6 | - [RNN结构](#rnn结构) 7 | - [总结](#总结) 8 | 9 | 10 | 11 | # 一文搞懂RNN（循环神经网络）基础篇 12 | 13 | 14 | ## 神经网络基础 15 | 16 | 神经网络可以当做是能够拟合任意函数的黑盒子，只要训练数据足够，给定特定的x，就能得到希望的y，结构图如下： 17 | 18 | ![base](pics/rnn_base.jpeg) 19 | 20 | 将神经网络模型训练好之后，在输入层给定一个x，通过网络之后就能够在输出层得到特定的y，那么既然有了这么强大的模型，为什么还需要RNN（循环神经网络）呢？ 21 | 22 | 23 | ## 为什么需要RNN（循环神经网络） 24 | 25 | 他们都只能单独的取处理一个个的输入，前一个输入和后一个输入是完全没有关系的。但是，某些任务需要能够更好的处理序列的信息，即前面的输入和后面的输入是有关系的。 26 | 27 | > 比如，当我们在理解一句话意思时，孤立的理解这句话的每个词是不够的，我们需要处理这些词连接起来的整个序列； 当我们处理视频的时候，我们也不能只单独的去分析每一帧，而要分析这些帧连接起来的整个序列。 28 | 29 | 很明显，一个句子中，前一个单词其实对于当前单词的词性预测是有很大影响的，比如预测苹果的时候，由于前面的吃是一个动词，那么很显然苹果作为名词的概率就会远大于动词的概率，因为动词后面接名词很常见，而动词后面接动词很少见。 30 | 31 | 所以为了解决一些这样类似的问题，能够更好的处理序列的信息，RNN就诞生了。 32 | 33 | 34 | ## RNN结构 35 | 36 | 首先看一个简单的循环神经网络如，它由输入层、一个隐藏层和一个输出层组成： 37 | 38 | ![simple](pics/rnn_simple.png) 39 | 40 | 不知道初学的同学能够理解这个图吗，反正我刚开始学习的时候是懵逼的，每个结点到底代表的是一个值的输入，还是说一层的向量结点集合，如何隐藏层又可以连接到自己，等等这些疑惑~这个图是一个比较抽象的图。 41 | 42 | 我们现在这样来理解，如果把上面有W的那个带箭头的圈去掉，它就变成了最普通的全连接神经网络。x是一个向量，它表示输入层的值（这里面没有画出来表示神经元节点的圆圈）；s是一个向量，它表示隐藏层的值（这里隐藏层面画了一个节点，你也可以想象这一层其实是多个节点，节点数与向量s的维度相同）； 43 | 44 | U是输入层到隐藏层的权重矩阵，o也是一个向量，它表示输出层的值；V是隐藏层到输出层的权重矩阵。 45 | 46 | 那么，现在我们来看看W是什么。循环神经网络的隐藏层的值s不仅仅取决于当前这次的输入x，还取决于上一次隐藏层的值s。权重矩阵 W就是隐藏层上一次的值作为这一次的输入的权重。 47 | 48 | 我们给出这个抽象图对应的具体图： 49 | 50 | ![t](pics/rnn_t.webp) 51 | 52 | **我们从上图就能够很清楚的看到，上一时刻的隐藏层是如何影响当前时刻的隐藏层的。** 53 | 54 | 如果我们把上面的图展开，**循环神经网络**也可以画成下面这个样子： 55 | 56 | ![rnn](pics/rnn.webp) 57 | 58 | 我们可以用下面的公式来表示循环神经网络的计算方法： 59 | 60 | ![func](pics/rnn_func.png) 61 | 62 | 63 | ## 总结 64 | 65 | 好了，到这里大概讲解了RNN最基本的几个知识点，能够帮助大家直观的感受RNN和了解为什么需要RNN，后续总结它的反向求导知识点。 66 | 67 | 最后给出RNN的总括图： 68 | 69 | ![detail](pics/rnn_detail.png) 70 | 71 | > 注意：为了简单说明问题，偏置都没有包含在公式里面。 72 | 73 | > refer to: https://zhuanlan.zhihu.com/p/30844905 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | -------------------------------------------------------------------------------- /aigc/rnn2.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [循环神经网络 – Recurrent Neural Network | RNN](#循环神经网络--recurrent-neural-network--rnn) 4 | - [为什么需要 RNN ？独特价值是什么？](#为什么需要-rnn-独特价值是什么) 5 | - [RNN 的基本原理](#rnn-的基本原理) 6 | - [RNN 的优化算法](#rnn-的优化算法) 7 | - [RNN 到 LSTM – 长短期记忆网络](#rnn-到-lstm--长短期记忆网络) 8 | - [从 LSTM 到 GRU](#从-lstm-到-gru) 9 | - [RNN 的应用和使用场景](#rnn-的应用和使用场景) 10 | - [总结](#总结) 11 | 12 | 13 | 14 | # 循环神经网络 – Recurrent Neural Network | RNN 15 | 16 | 卷积神经网络 – CNN 已经很强大的，为什么还需要RNN？ 17 | 18 | 本文会用通俗易懂的方式来解释 RNN 的独特价值——处理序列数据。同时还会说明 RNN 的一些缺陷和它的变种算法。 19 | 20 | 最后给大家介绍一下 RNN 的实际应用价值和使用场景。 21 | 22 | 23 | ## 为什么需要 RNN ？独特价值是什么？ 24 | 25 | 卷积神经网络 – CNN 和普通的算法大部分都是输入和输出的一一对应，也就是一个输入得到一个输出。不同的输入之间是没有联系的。 26 | 27 | ![input-output](pics/input-output.png.webp) 28 | 29 | 但是在某些场景中，一个输入就不够了！ 30 | 31 | 为了填好下面的空，取前面任何一个词都不合适，我们不但需要知道前面所有的词，还需要知道词之间的顺序。 32 | 33 | ![tiankong](pics/tiankong.png.webp) 34 | 35 | **这种需要处理「序列数据 – 一串相互依赖的数据流」的场景就需要使用 RNN 来解决了。** 36 | 37 | 典型的集中序列数据： 38 | 39 | - 文章里的文字内容 40 | - 语音里的音频内容 41 | - 股票市场中的价格走势 42 | - …… 43 | 44 | RNN 之所以能够有效的处理序列数据，主要是基于他的比较特殊的运行原理。下面给大家介绍一下 RNN 的基本运行原理。 45 | 46 | 47 | ## RNN 的基本原理 48 | 49 | 传统神经网络的结构比较简单：输入层 – 隐藏层 – 输出层。如下图所示： 50 | 51 | ![chuantong](pics/chuantong.png.webp) 52 | 53 | RNN 跟传统神经网络最大的区别在于每次都会将前一次的输出结果，带到下一次的隐藏层中，一起训练。如下图所示： 54 | 55 | ![rnn-1](pics/rnn-1.gif) 56 | 57 | 下面用一个具体的案例来看看 RNN 是如何工作的： 58 | 59 | 假如需要判断用户的说话意图（问天气、问时间、设置闹钟…），用户说了一句“what time is it？”我们需要先对这句话进行分词： 60 | 61 | ![fenci](pics/fenci.gif) 62 | 63 | 然后按照顺序输入 RNN ，我们先将 “what”作为 RNN 的输入，得到输出「01」 64 | 65 | ![input-what](pics/input-what.gif) 66 | 67 | 然后，我们按照顺序，将“time”输入到 RNN 网络，得到输出「02」。 68 | 69 | 这个过程我们可以看到，输入 “time” 的时候，**前面 “what” 的输出也产生了影响（隐藏层中有一半是黑色的）。** 70 | 71 | ![input-time](pics/input-time.gif) 72 | 73 | 以此类推，前面所有的输入都对未来的输出产生了影响，大家可以看到圆形隐藏层中包含了前面所有的颜色。如下图所示： 74 | 75 | ![input-5](pics/input-5.gif) 76 | 77 | 当我们判断意图的时候，只需要最后一层的输出「05」，如下图所示： 78 | 79 | ![output](pics/output.gif) 80 | 81 | **RNN 的缺点也比较明显** 82 | 83 | ![quedian](pics/quedian.jpg.webp) 84 | 85 | 通过上面的例子，我们已经发现，短期的记忆影响较大（如橙色区域），但是长期的记忆影响就很小（如黑色和绿色区域），这就是 RNN 存在的短期记忆问题。 86 | 87 | - RNN 有短期记忆问题，无法处理很长的输入序列 88 | - 训练 RNN 需要投入极大的成本 89 | 90 | 由于 RNN 的短期记忆问题，后来又出现了基于 RNN 的优化算法，下面给大家简单介绍一下。 91 | 92 | 93 | ## RNN 的优化算法 94 | 95 | 96 | ### RNN 到 LSTM – 长短期记忆网络 97 | 98 | RNN 是一种死板的逻辑，越晚的输入影响越大，越早的输入影响越小，且无法改变这个逻辑。 99 | 100 | LSTM 做的最大的改变就是打破了这个死板的逻辑，而改用了一套灵活了逻辑——只保留重要的信息。 101 | 102 | **简单说就是：抓重点！** 103 | 104 | ![rnn-lstm](pics/rnn-lstm.png.webp) 105 | 106 | 举个例子，我们先快速的阅读下面这段话： 107 | 108 | ![pinglun](pics/pinglun.png.webp) 109 | 110 | 当我们快速阅读完之后，可能只会记住下面几个重点： 111 | 112 | ![pinglun-hzd](pics/pinglun-hzd.png.webp) 113 | 114 | LSTM 类似上面的划重点，他可以保留较长序列数据中的「重要信息」，忽略不重要的信息。这样就解决了 RNN 短期记忆的问题。 115 | 116 | 具体技术上的实现原理就不在这里展开了，感兴趣的可以看看 LSTM 的详细介绍[《长短期记忆网络 – LSTM》](https://easyai.tech/ai-definition/lstm/) 117 | 118 | 119 | ### 从 LSTM 到 GRU 120 | 121 | Gated Recurrent Unit – GRU 是 LSTM 的一个变体。他保留了 LSTM 划重点，遗忘不重要信息的特点，在long-term 传播的时候也不会被丢失。 122 | 123 | ![lstm-gru](pics/lstm-gru.png.webp) 124 | 125 | GRU 主要是在 LSTM 的模型上做了一些简化和调整，在训练数据集比较大的情况下可以节省很多时间。 126 | 127 | 128 | ## RNN 的应用和使用场景 129 | 130 | 只要涉及到序列数据的处理问题，都可以使用到，NLP 就是一个典型的应用场景。 131 | 132 | ![yingyong](pics/yingyong.png.webp) 133 | 134 | **文本生成**：类似上面的填空题，给出前后文，然后预测空格中的词是什么。 135 | 136 | **机器翻译**：翻译工作也是典型的序列问题，词的顺序直接影响了翻译的结果。 137 | 138 | **语音识别**：根据输入音频判断对应的文字是什么。 139 | 140 | **生成图像描述**：类似看图说话，给一张图，能够描述出图片中的内容。这个往往是 RNN 和 CNN 的结合。 141 | 142 | ![kantu](pics/kantu.png.webp) 143 | 144 | **视频标记**：他将视频分解为图片，然后用图像描述来描述图片内容。 145 | 146 | 147 | ## 总结 148 | 149 | RNN的独特价值在于：它能有效的处理序列数据。比如：文章内容、语音音频、股票价格走势… 150 | 151 | 之所以他能处理序列数据，是因为在序列中前面的输入也会影响到后面的输出，相当于有了“记忆功能”。但是 RNN 存在严重的短期记忆问题，长期的数据影响很小（哪怕他是重要的信息）。 152 | 153 | 于是基于 RNN 出现了 LSTM 和 GRU 等变种算法。这些变种算法主要有几个特点： 154 | 155 | - 长期信息可以有效的保留 156 | - 挑选重要信息保留，不重要的信息会选择“遗忘” 157 | 158 | RNN 几个典型的应用如下： 159 | 160 | - 文本生成 161 | - 语音识别 162 | - 机器翻译 163 | - 生成图像描述 164 | - 视频标记 165 | 166 | > refer to: https://easyai.tech/ai-definition/rnn/ 167 | -------------------------------------------------------------------------------- /aigc/rnn3.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [RNN 扩展](#rnn-扩展) 4 | - [双向RNN(Bidirectional RNNs)](#双向rnnbidirectional-rnns) 5 | - [深度双向RNN(Deep Bidirectional RNNs)](#深度双向rnndeep-bidirectional-rnns) 6 | 7 | 8 | 9 | # RNN 扩展 10 | 11 | 12 | ## 双向RNN(Bidirectional RNNs) 13 | 14 | 双向RNN如下图所示，它的思想是t时刻的输出不但依赖于之前的元素，而且还依赖之后的元素。比如，我们做完形填空，在句子中“挖”掉一个词，我们想预测这个词，我们不但会看前面的词，也会分析后面的词。双向RNN很简单，它就是两个RNN堆叠在一起，输出依赖两个RNN的隐状态。 15 | 16 | ![bidirectional-rnn](pics/bidirectional-RNN.png) 17 | 18 | 19 | ## 深度双向RNN(Deep Bidirectional RNNs) 20 | 21 | 深度双向RNN如下图所示，它和双向RNN类似，不过多加几层。当然它的表示能力更强，需要的训练数据也更多。 22 | 23 | ![stacked-bidirectional-RNN](pics/stacked-bidirectional-RNN.png) 24 | 25 | > refer to: http://fancyerii.github.io/books/rnn-intro/ 26 | 27 | -------------------------------------------------------------------------------- /aigc/transformer/pics/1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/1.png -------------------------------------------------------------------------------- /aigc/transformer/pics/10.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/10.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/11.png -------------------------------------------------------------------------------- /aigc/transformer/pics/12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/12.png -------------------------------------------------------------------------------- /aigc/transformer/pics/13.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/13.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/14.png -------------------------------------------------------------------------------- /aigc/transformer/pics/15.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/15.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/16.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/16.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/17.png -------------------------------------------------------------------------------- /aigc/transformer/pics/18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/18.png -------------------------------------------------------------------------------- /aigc/transformer/pics/19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/19.png -------------------------------------------------------------------------------- /aigc/transformer/pics/2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/2.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/20.png -------------------------------------------------------------------------------- /aigc/transformer/pics/21.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/21.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/22.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/22.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/23.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/23.png -------------------------------------------------------------------------------- /aigc/transformer/pics/24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/24.png -------------------------------------------------------------------------------- /aigc/transformer/pics/25.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/25.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/26.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/26.png -------------------------------------------------------------------------------- /aigc/transformer/pics/27.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/27.png -------------------------------------------------------------------------------- /aigc/transformer/pics/28.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/28.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/29.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/29.png -------------------------------------------------------------------------------- /aigc/transformer/pics/3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/3.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/4.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/4.jpeg -------------------------------------------------------------------------------- /aigc/transformer/pics/5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/5.png -------------------------------------------------------------------------------- /aigc/transformer/pics/6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/6.png -------------------------------------------------------------------------------- /aigc/transformer/pics/7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/7.png -------------------------------------------------------------------------------- /aigc/transformer/pics/8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/8.png -------------------------------------------------------------------------------- /aigc/transformer/pics/9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/aigc/transformer/pics/9.png -------------------------------------------------------------------------------- /apm/apm.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [APM 简述](#apm-简述) 4 | - [APM 概念框架](#apm-概念框架) 5 | - [APM 核心功能](#apm-核心功能) 6 | - [APM 数据采集方式](#apm-数据采集方式) 7 | - [代码潜入](#代码潜入) 8 | - [旁路监听](#旁路监听) 9 | - [日志分析](#日志分析) 10 | - [模拟拨测](#模拟拨测) 11 | - [SNMP接口](#snmp接口) 12 | 13 | 14 | 15 | 16 | # APM 简述 17 | 18 | APM，Application Performance Management，应用性能监控，对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。 19 | 20 | 最早的APM主要是网络为中心，对基础设备的性能数据进行收集与加工，并提供给企业客户，相当于提供一种事后数据的简单处理与告警监控功能。随着APM市场的发展，目前的 APM 工具在性能监控的基础上有了进化，更加关注于运维数据分析，比如客户端到端的体验情况怎么样？性能瓶颈在哪里？而且当前的 APM 工具以数据分析为中间实现了更好的可视化，更快更精准预警，更强的问题关联定位等特性。 21 | 22 | 随着分布式系统和微服务架构的应用和发展，应用性能管理成为系统运维管理和网络管理的一个重要方向，它能够对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。应用性能管理APM能够对整个企业的IT系统各个层面进行集中的性能监控，并对有可能出现的性能问题进行及时、准确的分析和处理。它能轻松地从一个IT应用系统中找到故障点，并提供有相关解决建议或方法，从而提高整体的系统性能。一个企业的关键业务应用的性能强大，可以保证企业业务应用系统的高效性和稳定性，为企业带来核心竞争力的提升。 23 | 24 | 25 | # APM 概念框架 26 | 27 | 随着互联网技术和应用的快速发展，应用程序本身变得越来越难以管理，因为它们从单体架构转向高度分布的、多层、多元素的分布式应用架构，应用系统在许多情况下依赖于应用程序的开发框架。APM概念框架旨在帮助企业优先考虑在IT系统架构中需要首先关注的方法，以便企业能够快速实施并全面了解五维APM模型。 28 | 29 | ![apm-conceptual-framework](pics/apm-conceptual-framework.png) 30 | 31 | - 终端用户体验 32 | 33 | 此测量的结果称为实时应用程序监视（又称自顶向下监视），它具有被动和主动两个组件。被动监控通常是使用网络端口镜像实现的无代理设备。主动监控由预定义的合成探针和Web机器人组成，用于报告系统可用性和业务事务（即业务方自行埋点）。 34 | 35 | - 运行时应用架构 36 | 37 | 更好的理解服务依赖映射。 38 | 39 | - 应用事务的分析 40 | 41 | - 深度应用诊断 42 | 43 | - 分析报告 44 | 45 | 46 | # APM 核心功能 47 | 48 | APM 主要包含如下核心功能： 49 | 50 | - 应用系统存活检测 51 | 52 | - 应用程序性能指标检测(CPU利用率、内存利用率等) 53 | 54 | - 应用程序关键事件检测 55 | 56 | - 检测数据持久化存储并能够多维度查询 57 | 58 | - 服务调用跟踪 59 | 60 | - 监控告警 61 | 62 | 下图 APM 核心的能力的列表： 63 | 64 | ![apm-function](pics/apm-function.jpg) 65 | 66 | 67 | # APM 数据采集方式 68 | 69 | 70 | ## 代码潜入 71 | 72 | 通过在 APP 中嵌入 SDK 采集移动端用户行为与体验数据；在网页中嵌入 JS 采集浏览器端用户行为与体验数据；在应用程序端嵌入 Agent 采集各种服务性能指标及运行时代码数据，这些数据通过安全网络传输到云端服务器，用户通过监控平台实现对数据的查看和管理。 73 | 74 | ![implant](pics/implant.png) 75 | 76 | - 优点 77 | - 能实现对代码、SQL脚本和服务问题进行诊断分析，监控的内容及问题定位更深入 78 | - 实现从用户端到服务层的针对用户真实行为的端到端应用性能监控 79 | 80 | - 缺点 81 | - 需要应用程序开发厂商配合，变更维护相对麻烦 82 | - 提供的 agent 要根据不同程序的不同开发语言进行适配，分支的语言和版本较多 83 | - 对系统性能有一定的影响 84 | 85 | 86 | ## 旁路监听 87 | 88 | 旁路监听型监控就是通过镜像交换机的方式，把出口数据复制一份到指定服务器，通过专业的旁路监听程序将数据包进行解析，从而达到监控的目的。 89 | 90 | ![image](pics/image.png) 91 | 92 | - 优点 93 | - 不中断正常业务 94 | - 不影响性能 95 | - 不使用探针或者插件 96 | - 不修改应用 97 | - 不需要人工介入 98 | 99 | - 缺点 100 | - 需要提供数据采集、分析、展现等方面的硬件资源，对服务器资源要求较高 101 | - 数据只能反映目前所采集到的流量情况，监控的细致程度受上报数据内容和格式的限制 102 | 103 | 104 | ## 日志分析 105 | 106 | 日志监控技术对运维日志、业务日志进行采集、搜索、分析、可视化，用于运维监控、安全审计、业务数据分析。 107 | 108 | ![log](pics/log.png) 109 | 110 | - 优点 111 | - 相比其他监控方式，监控的指标可以灵活定义、指标更全面、数据更完善 112 | - 能够深入到业务级别进行监控，监控的指标与业务结合更紧密 113 | 114 | - 缺点 115 | - 被监控的系统通常需要配合改造或输出符合规范格式的业务日志 116 | - 需要对海量日志数据进行储存，对存储有较高的要求，服务器资源消耗相对大 117 | - 与业务紧密藕合，复用度较差，实现成本较高 118 | 119 | 120 | ## 模拟拨测 121 | 122 | 模拟拨测主要通过程序模拟用户行为进行系统操作，实现对业务进行自动拨测、识别并记录拨测过程及结果。 123 | 124 | ![simulate](pics/simulate.png) 125 | 126 | - 优点 127 | - 贴近用户操作和感受，完全模拟人手工操作 128 | - 提供24小时不间断的监控服务，能够比用户更早发现系统中存在的问题 129 | - 灵活配置基础资源及监控节点 130 | 131 | - 缺点 132 | - 数据的精确程度取决于拨测设备的数量和拨测频率，如果需要做到相对精确，对拨测环境的要求较高 133 | - 采集的数据为模拟用户操作行为的数据，而非用户真实体验数据 134 | - 对于静态网站地址的拨测比较方便，对于动态网站信息拨测需要录制维护脚本比较麻烦，且受验证码的限制 135 | 136 | 137 | ## SNMP接口 138 | 139 | 简单网络管理协议（SNMP），由一组网络管理的标准组成，包含一个应用层协议（applicationlayerprotocol）、数据库模型（databaseschema）和一组资源对象。该协议能够支持网络管理系统，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。 140 | 141 | ![snmp](pics/snmp.png) 142 | 143 | - 优点 144 | - 通用性高，不管什么平台、什么设备，任何能实现 SNMP 协议的软件都可对其进行监测 145 | - 部署简单，服务器只需要开通 SNMP 协议，经过简单的配置，便可实现服务器性能监控 146 | 147 | - 缺点 148 | - 监测有参数指标比较固定不够深入，如用户有特殊需求无法通过定制开发满足 149 | - 通过 UDP 方式实现，在网络状况不佳的情况下其可靠性难以保证 150 | -------------------------------------------------------------------------------- /apm/pics/apk.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/apk.jpg -------------------------------------------------------------------------------- /apm/pics/apm-conceptual-framework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/apm-conceptual-framework.png -------------------------------------------------------------------------------- /apm/pics/apm-function.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/apm-function.jpg -------------------------------------------------------------------------------- /apm/pics/cellphone-apm.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/cellphone-apm.jpg -------------------------------------------------------------------------------- /apm/pics/compare-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/compare-1.png -------------------------------------------------------------------------------- /apm/pics/compare-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/compare-2.png -------------------------------------------------------------------------------- /apm/pics/image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/image.png -------------------------------------------------------------------------------- /apm/pics/implant.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/implant.png -------------------------------------------------------------------------------- /apm/pics/log.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/log.png -------------------------------------------------------------------------------- /apm/pics/simulate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/simulate.png -------------------------------------------------------------------------------- /apm/pics/skywalking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/skywalking.png -------------------------------------------------------------------------------- /apm/pics/snmp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/snmp.png -------------------------------------------------------------------------------- /apm/pics/代码插入.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/代码插入.png -------------------------------------------------------------------------------- /apm/pics/动态代理.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/动态代理.png -------------------------------------------------------------------------------- /apm/pics/可视化埋点.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/可视化埋点.png -------------------------------------------------------------------------------- /apm/pics/可视化埋点流程.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/可视化埋点流程.png -------------------------------------------------------------------------------- /apm/pics/技术方案.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/技术方案.png -------------------------------------------------------------------------------- /apm/pics/数据维度.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/数据维度.png -------------------------------------------------------------------------------- /apm/pics/静态代理.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/apm/pics/静态代理.png -------------------------------------------------------------------------------- /apm/服务端-apm.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [监控对象](#监控对象) 4 | - [数据维度](#数据维度) 5 | - [业务维度](#业务维度) 6 | - [APM 工具对比](#apm-工具对比) 7 | - [skywalking 部署架构](#skywalking-部署架构) 8 | 9 | 10 | 11 | 12 | # 监控对象 13 | 14 | 15 | ## 数据维度 16 | 17 | ![数据维度](pics/数据维度.png) 18 | 19 | 从数据类型划分，大体可分为： 20 | 21 | - 日志（logs）：自动埋点/手动埋点 22 | - 指标监控(metrics)：服务、端点、实例的各项指标 23 | - 调用链(tracing): 同一 TraceId 的调用序列 24 | 25 | 26 | ## 业务维度 27 | 28 | 从业务角度划分，可分为： 29 | 30 | - 基础资源监控 31 | - 服务器监控：cpu、内存、磁盘 IO、网络 IO、本地磁盘 32 | - 网络监控 33 | - 设备监控：主要针对数据中心内的多种网络设备进行监控。包括路由器，防火墙和交换机等硬件设备，可以通过 snmp 等协议收集数据。 34 | - 网络性能监控：主要涉及网络监测，网络实时流量监控（网络延迟、访问量、成功率）和历史数据统计、汇总和历史数据分析等功能。 35 | - 网络安全检测：主要针对内网或者外网的网络攻击。如DDoS攻击。通过分析异常流量来确定网络攻击行为。 36 | - 存储监控 37 | - 存储设备监控：对于构建在 x86 服务器上的存储设备，设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，通常自带监控功能，可监控设备的运行状态，性能和容量的。 38 | - 存储性能监控：存储通常监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储通常监控文件系统 inode。读写速度、目录权限等。 39 | - 存储系统监控：不同的存储系统有不同的指标，例如，对于 ceph 存储需要监控 OSD, MON 的运行状态，各种状态 pg 的数量以及集群 IOPS 等信息。 40 | - 中间件监控：kafka Db Redis Zk 等依赖项的性能 41 | - 应用程序监控（APM） 42 | 43 | Prometheus 既适合系统层的监控，也适合应用层监控。但是不适合做应用程序 APM。因为 APM 包括应用程序的运行状态监控，性能监控，日志监控及调用链跟踪等的监控。 44 | 45 | 应用程序监控工具除了有 Pinpoint，还有 Twitter 开源的 Zipkin，Apache SkyWalking，美团开源的 CAT等。 46 | 47 | 48 | # APM 工具对比 49 | 50 | ![compare-1](pics/compare-1.png) 51 | ![compare-2](pics/compare-2.png) 52 | 53 | 54 | # skywalking 部署架构 55 | 56 | ![skywalking](pics/skywalking.png) 57 | -------------------------------------------------------------------------------- /apm/移动应用类型.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | - [移动应用类型](#移动应用类型) 4 | - [Native App](#native-app) 5 | - [Web App](#web-app) 6 | - [Hybrid App](#hybrid-app) 7 | 8 | 9 | 10 | 11 | # 移动应用类型 12 | 13 | 14 | ## Native App 15 | 16 | Native App 是一种基于智能手机本地操作系统如 iOS、Android 并使用特定的编程语言编写的第三方应用程序，也叫本地app。iOS 操作系统上一般使用的开发语言为 Objective-C。Android 操作系统上一般使用的开发语言为 Java。 17 | 18 | 优点： 19 | 1. 提供最佳用户体验，最优质的用户界面，流畅的交互 20 | 2. 可以访问本地资源 21 | 3. 可以调用移动硬件设备，比如摄像头、麦克风等 22 | 23 | 缺点： 24 | 1. 开发成本高。每种移动操作系统都需要独立的开发项目，针对不同平台提供不同体验。 25 | 2. 发布新版本慢。下载是用户控制的，很多用户不愿意下载更新（比如说，版本发布到了3.0，但还是有很多1.0的用户，你可能就得继续维护1.0版本的 API）。 26 | 3. 应用商店发布审核周期长。安卓平台大概要1~3天，而 iOS 平台需要的时间更长。 27 | 28 | 29 | ## Web App 30 | 31 | Web App 是基于 Html5 语言做触摸操作的网站，也叫 H5 或 M 站，不需要下载安装。生存在浏览器中的轻应用。 32 | 33 | 优点： 34 | 1. 不需要安装包，节约手机空间 35 | 2. 整体量级轻，开发成本低 36 | 3. 不需要用户进行手动更新，由应用开发者直接在后台更新，推送到用户面前的都是全新版本，更便于业务的开展 37 | 4. 基于浏览器，可以跨平台使用 38 | 39 | 缺点： 40 | 1. 浏览器提供的 API（即 Web API）很有限（目前只有相机、GPS、电池等少数几个），大部分系统硬件都不能通过网页访问，也无法直接读取硬盘文件，所以 Web App 无法充分利用平台的硬件。 41 | 2. 网页通过浏览器渲染，性能不如原生 App，不适合做性能要求较高的页面。 42 | 3. Web App 需要打开浏览器才能使用，这意味着，用户必须记住如何导航到它，要么直接输入网址，要么翻找书签。这使得进入 Web App，远不如原生 App 方便。 43 | 44 | 45 | ## Hybrid App 46 | 47 | 顾名思义，就是 Native App 与 Web App 的混合。在 Native App 里内置浏览器，合适的功能页面采用网页的形式呈现。比如京东的某些营销页面，今日头条的某些新闻页面、微信的腾讯新闻的内容页面等。 48 | 49 | 优点： 50 | 1. 在实现更多功能的前提下，使得 App 安装包不至于过大。 51 | 2. 在应用内部打开 Web 网页，省去了跳转浏览器的麻烦。 52 | 3. 主要功能区相对稳定下，增加的功能区采用 Web 形式，使得迭代更加方便。 53 | 4. Web 页面在用户设置不同的网络制式时会以不同的形式呈现（以微信朋友圈为例，在数据流量下，设置 APNS 为 WAP 时，微信订阅号内容将屏蔽图片和视频。这样就能为用户省去一部分流量。） 54 | 5. 手机功能都可访问。 55 | 56 | 缺点： 57 | 1. 用户体验还是不如 Native APP。 58 | 2. 速度相对于 Native APP 较慢，大量界面需要连接网络。 59 | 60 | -------------------------------------------------------------------------------- /cache/listers.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [StoreToXXXXLister](#storetoxxxxlister) 6 | - [StoreToPodLister](#storetopodlister) 7 | 8 | 9 | 10 | delta_fifo、undelta_fifo、expiration_cache 跟前面的 Store 和 FIFO 差不多，不再详细分析。下面简单分析一下 listers。 11 | 12 | # StoreToXXXXLister 13 | 14 | StoreToXXXXLister 实际上就是一个 Store，唯一的不同就是主要实现了某类特定资源的 list 函数（可能还会根据需要实现了其他的一些函数）。下面举个例子。 15 | 16 | ## StoreToPodLister 17 | 18 | ``` 19 | // TODO: generate these classes and methods for all resources of interest using 20 | // a script. Can use "go generate" once 1.4 is supported by all users. 21 | 22 | // StoreToPodLister makes a Store have the List method of the client.PodInterface 23 | // The Store must contain (only) Pods. 24 | // 25 | // Example: 26 | // s := cache.NewStore() 27 | // lw := cache.ListWatch{Client: c, FieldSelector: sel, Resource: "pods"} 28 | // r := cache.NewReflector(lw, &api.Pod{}, s).Run() 29 | // l := StoreToPodLister{s} 30 | // l.List() 31 | type StoreToPodLister struct { 32 | Store 33 | } 34 | 35 | // Please note that selector is filtering among the pods that have gotten into 36 | // the store; there may have been some filtering that already happened before 37 | // that. 38 | // 39 | // TODO: converge on the interface in pkg/client. 40 | func (s *StoreToPodLister) List(selector labels.Selector) (pods []*api.Pod, err error) { 41 | // TODO: it'd be great to just call 42 | // s.Pods(api.NamespaceAll).List(selector), however then we'd have to 43 | // remake the list.Items as a []*api.Pod. So leave this separate for 44 | // now. 45 | for _, m := range s.Store.List() { 46 | pod := m.(*api.Pod) 47 | if selector.Matches(labels.Set(pod.Labels)) { 48 | pods = append(pods, pod) 49 | } 50 | } 51 | return pods, nil 52 | } 53 | 54 | // Pods is taking baby steps to be more like the api in pkg/client 55 | func (s *StoreToPodLister) Pods(namespace string) storePodsNamespacer { 56 | return storePodsNamespacer{s.Store, namespace} 57 | } 58 | 59 | type storePodsNamespacer struct { 60 | store Store 61 | namespace string 62 | } 63 | 64 | // Please note that selector is filtering among the pods that have gotten into 65 | // the store; there may have been some filtering that already happened before 66 | // that. 67 | func (s storePodsNamespacer) List(selector labels.Selector) (pods api.PodList, err error) { 68 | list := api.PodList{} 69 | for _, m := range s.store.List() { 70 | pod := m.(*api.Pod) 71 | if s.namespace == api.NamespaceAll || s.namespace == pod.Namespace { 72 | if selector.Matches(labels.Set(pod.Labels)) { 73 | list.Items = append(list.Items, *pod) 74 | } 75 | } 76 | } 77 | return list, nil 78 | } 79 | 80 | // Exists returns true if a pod matching the namespace/name of the given pod exists in the store. 81 | func (s *StoreToPodLister) Exists(pod *api.Pod) (bool, error) { 82 | _, exists, err := s.Store.Get(pod) 83 | if err != nil { 84 | return false, err 85 | } 86 | return exists, nil 87 | } 88 | ``` 89 | 90 | StoreToPodLister 实现了三个方法： 91 | 92 | - func (s *StoreToPodLister) List(selector labels.Selector) (pods []*api.Pod, err error)：列出匹配 lable selector 的所有 pod。 93 | - func (s *StoreToPodLister) Pods(namespace string) storePodsNamespacer：以 store 的形式返回属于同一 namespace 的所有 pod，storePodsNamespacer 就是存储属于同一 namespace pod 的。 94 | - func (s *StoreToPodLister) Exists(pod *api.Pod) (bool, error)：判断某个 pod 是否存在。 95 | -------------------------------------------------------------------------------- /contiv/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [netplugin 分析系列](#netplugin-%E5%88%86%E6%9E%90%E7%B3%BB%E5%88%97) 6 | 7 | 8 | 9 | # netplugin 分析系列 10 | 11 | - [netplugin 分析一：contiv 基本概念](./contiv基本概念分析.md) 12 | - [netplugin 分析二：contivk8s cni 框架代码分析](./contivk8s-cni分析.md) 13 | - [netplugin 分析二：netplugin 框架代码分析](./netplugin分析.md) 14 | - netplugin 分析三：netmaster 框架代码分析 15 | * [netmaster 分析-1](./netmaster分析-1.md) 16 | * [netmaster 分析-2](./netmaster分析-2.md) 17 | * [netmaster 分析-3](./netmaster分析-3.md) 18 | - [network driver 分析](network-driver.md) 19 | - [network 分析](network分析.md) 20 | - [endpointgroup 分析](endpointgroup分析.md) 21 | - [policy 分析](policy分析.md) 22 | - [rule 分析](rule分析.md) 23 | - [netprofile 分析](netprofile分析.md) 24 | -------------------------------------------------------------------------------- /contiv/netmaster分析-3.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [IP Address Management (IPAM)](#ip-address-management-ipam) 6 | - [Subnet IP Pool](#subnet-ip-pool) 7 | - [Service Discovery](#service-discovery) 8 | 9 | 10 | 11 | # IP Address Management (IPAM) 12 | 13 | Contiv allocates a unique IP address for every container. An IP address allocated to a container is not bound to an application group or microservice tier. Every container simply gets an IP address from the subnet pool. Unlike some of the container networking solutions that require a subnet per host, the Contiv solution does not have such limitations. This also makes Contiv truly multi-tenant. You can have overlapping IP addresses across tenants. 14 | 15 | # Subnet IP Pool 16 | 17 | You can specify the IP address pool to be used for a network using the -subnet argument while creating the network. You can specify the entire CIDR range or a smaller range. 18 | 19 | In the following example, contiv-net has an IP address pool that is a subset of the CIDR range from address 10.1.1.50 to 10.1.1.100. 20 | 21 | ``` 22 | $ netctl network create contiv-net -subnet 10.1.1.50-10.1.1.100/24 23 | ``` 24 | 25 | When you start a container in contiv-net, it will get an IP address from this smaller IP address pool: 26 | 27 | ``` 28 | $ docker run -itd --net contiv-net --name app1 alpine sh 29 | c33f5920074e0807db442a65238fdc77018e6ad553022e78ac51509f74cedf49 30 | $ docker exec -it app1 sh 31 | / # ifconfig eth0 32 | eth0 Link encap:Ethernet HWaddr 02:02:0A:01:01:34 33 | inet addr:10.1.1.52 Bcast:0.0.0.0 Mask:255.255.255.0 34 | inet6 addr: fe80::2:aff:fe01:134%32588/64 Scope:Link 35 | UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1 36 | RX packets:8 errors:0 dropped:0 overruns:0 frame:0 37 | TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 38 | collisions:0 txqueuelen:0 39 | RX bytes:648 (648.0 B) TX bytes:648 (648.0 B) 40 | 41 | / # 42 | ``` 43 | 44 | # Service Discovery 45 | 46 | Contiv provides built-in service discovery for all containers in the network. Unlike traditional service discovery tools which require applications to query external key-value stores for container IP and port information, Contiv service discovery uses standard DNS protocol and requires no changes to the application. 47 | 48 | When a container is attached to an endpoint group (EPG), it automatically becomes reachable by DNS name. For example, consider a container attached to the production-web EPG. This container becomes available by DNS name production-web for all other containers in the same tenant. If there are multiple containers in the same EPG, all of them are available by the same DNS service name. DNS queries are load-balanced across all containers in the group. 49 | 50 | Similarly, all service load balancers created using Contiv are also available for DNS query by service name. 51 | -------------------------------------------------------------------------------- /contiv/network-driver.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [network driver](#network-driver) 6 | 7 | 8 | 9 | # network driver 10 | 11 | ![network driver](pics/network-driver.png) 12 | 13 | vlanbridge datapath: 14 | 15 | ![vlanbridge datapath](pics/datapath-vlanbridge.png) 16 | -------------------------------------------------------------------------------- /contiv/pics/bgp-sm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/bgp-sm.png -------------------------------------------------------------------------------- /contiv/pics/bgp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/bgp.png -------------------------------------------------------------------------------- /contiv/pics/contiv-dns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/contiv-dns.png -------------------------------------------------------------------------------- /contiv/pics/contiv-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/contiv-model.png -------------------------------------------------------------------------------- /contiv/pics/datapath-vlanbridge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/datapath-vlanbridge.png -------------------------------------------------------------------------------- /contiv/pics/epg-create.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/epg-create.png -------------------------------------------------------------------------------- /contiv/pics/epg-delete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/epg-delete.png -------------------------------------------------------------------------------- /contiv/pics/netprofile-create.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/netprofile-create.png -------------------------------------------------------------------------------- /contiv/pics/netprofile-delete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/netprofile-delete.png -------------------------------------------------------------------------------- /contiv/pics/network-create.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/network-create.png -------------------------------------------------------------------------------- /contiv/pics/network-delete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/network-delete.png -------------------------------------------------------------------------------- /contiv/pics/network-driver.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/network-driver.png -------------------------------------------------------------------------------- /contiv/pics/ofnet-arch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/ofnet-arch.jpg -------------------------------------------------------------------------------- /contiv/pics/ofnet-datapath.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/ofnet-datapath.jpg -------------------------------------------------------------------------------- /contiv/pics/policy-create.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/policy-create.png -------------------------------------------------------------------------------- /contiv/pics/policy-delete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/policy-delete.png -------------------------------------------------------------------------------- /contiv/pics/rule-create.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/rule-create.png -------------------------------------------------------------------------------- /contiv/pics/rule-delete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/contiv/pics/rule-delete.png -------------------------------------------------------------------------------- /dynamic-volume-provisioner/Kubernetes存储概览-Volume-Provisioner代码分析.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/dynamic-volume-provisioner/Kubernetes存储概览-Volume-Provisioner代码分析.pdf -------------------------------------------------------------------------------- /dynamic-volume-provisioner/nfs-client-provisioner源码分析.webarchive: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/dynamic-volume-provisioner/nfs-client-provisioner源码分析.webarchive -------------------------------------------------------------------------------- /dynamic-volume-provisioner/利用NFS动态提供Kubernetes后端存储卷.webarchive: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/dynamic-volume-provisioner/利用NFS动态提供Kubernetes后端存储卷.webarchive -------------------------------------------------------------------------------- /k8s-operator-example/kube-rbac-proxy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s-operator-example/kube-rbac-proxy.png -------------------------------------------------------------------------------- /k8s-operator-example/kubebuilder-core.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s-operator-example/kubebuilder-core.png -------------------------------------------------------------------------------- /k8s-operator-example/kustomize-base.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s-operator-example/kustomize-base.png -------------------------------------------------------------------------------- /k8s-operator-example/kustomize.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s-operator-example/kustomize.jpeg -------------------------------------------------------------------------------- /k8s-operator-example/readme.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s-operator-example/readme.pdf -------------------------------------------------------------------------------- /k8s/Kubernetes-ResourceQuota-Controller内部实现原理及源码分析.webarchive: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/Kubernetes-ResourceQuota-Controller内部实现原理及源码分析.webarchive -------------------------------------------------------------------------------- /k8s/api.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [API Machinery](#api-machinery) 6 | - [API对象](#api%E5%AF%B9%E8%B1%A1) 7 | - [API Package](#api-package) 8 | 9 | 10 | 11 | # API Machinery 12 | 13 | The Kubernetes API has two major components - the internal structures and the versioned APIs. The versioned APIs are intended to be stable, while the internal structures are implemented to best reflect the needs of the Kubernetes code itself. 14 | 15 | As mentioned above, the internal representation of an API object is decoupled from any one API version. This provides a lot of freedom to evolve the code, but it requires robust infrastructure to convert between representations. There are multiple steps in processing an API operation - even something as simple as a GET involves a great deal of machinery. 16 | 17 | The conversion process is logically a "star" with the internal form at the center. Every versioned API can be converted to the internal form (and vice-versa), but versioned APIs do not convert to other versioned APIs directly. This sounds like a heavy process, but in reality we do not intend to keep more than a small number of versions alive at once. While all of the Kubernetes code operates on the internal structures, they are always converted to a versioned form before being written to storage (disk or etcd) or being sent over a wire. Clients should consume and operate on the versioned APIs exclusively. 18 | 19 | To demonstrate the general process, here is a (hypothetical) example: 20 | 21 | A user POSTs a Pod object to /api/v7beta1/... 22 | The JSON is unmarshalled into a v7beta1.Pod structure [decode] 23 | Default values are applied to the v7beta1.Pod 24 | The v7beta1.Pod is converted to an api.Pod structure [convert] 25 | The api.Pod is validated, and any errors are returned to the user 26 | The api.Pod is converted to a v6.Pod (because v6 is the latest stable version) [convert] 27 | The v6.Pod is marshalled into JSON and written to etcd [encode] 28 | 29 | Now that we have the Pod object stored, a user can GET that object in any supported api version. For example: 30 | 31 | A user GETs the Pod from /api/v5/... 32 | The JSON is read from etcd and unmarshalled into a v6.Pod structure [decode] 33 | Default values are applied to the v6.Pod 34 | The v6.Pod is converted to an api.Pod structure [convert] 35 | The api.Pod is converted to a v5.Pod structure [convert] 36 | The v5.Pod is marshalled into JSON and sent to the user [encode] 37 | 38 | Most operations conducted by clients against the server are done using the primary API of the server (today, v1). Internally, we must maintain a version of code that can be converted to all other API versions - we call this the internal version and it is denoted in the scheme as __internal. All API operations start in a serialized form (either from a client or from etcd), are read as bytes / strings, loaded into a Go struct (known as an external type), defaulting is provided, then the object is converted to the internal API version and passed to the API machinery. The value either then is sent to etcd or back to the client in a reversed process. 39 | 40 | Our internal objects track the primary external version quite closely, we end up maintaining N+1 versions of our objects instead of just N, and we generally require all objects to be 100% convertible to all supported API versions by introducing new fields on older versions that match the newer API version. 41 | 42 | # API对象 43 | 44 | API 对象是 K8s 集群中的管理操作单元。K8s 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，支持对该功能的管理操作。例如副本集 Replica Set 对应的 API 对象是 RS。 45 | 46 | 每个 API 对象都有3大类属性：元数据 metadata、规范 spec 和状态 status。 47 | 48 | 元数据是用来标识 API 对象的，每个对象都至少有3个元数据：namespace，name 和 uid；除此以外还有各种各样的标签 labels 用来标识和匹配不同的对象，例如用户可以用标签 env 来标识区分不同的服务部署环境，分别用 env=dev、env=testing、env=production 来标识开发、测试、生产的不同服务。 49 | 50 | 规范描述了用户期望 K8s 集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器 Replication Controller 设置期望的 Pod 副本数为3。 51 | 52 | 状态描述了系统实际当前达到的状态（Status），例如系统当前实际的 Pod 副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的 Pod，争取达到副本数为3。 53 | 54 | K8s 中所有的配置都是通过 API 对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是 k8s 重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为3的操作运行多次也还是一个结果，而给副本数加1的操作就不是声明式的，运行多次结果就错了。 55 | 56 | # API Package 57 | 58 | ![API Package](pics/package-api.png) 59 | 60 | Package api contains the latest (or "internal") version of the Kubernetes API objects. This is the API objects as represented in memory. The contract presented to clients is located in the versioned packages, which are sub-directories. The first one is "v1beta1". Those packages describe how a particular version is serialized to storage/network. 61 | -------------------------------------------------------------------------------- /k8s/clean-null-docker-image.sh: -------------------------------------------------------------------------------- 1 | !/bin/bash 2 | 3 | docker ps -a|awk '{print $1}'|xargs docker rm 4 | docker rmi $(docker images -f "dangling=true" -q) 5 | 6 | -------------------------------------------------------------------------------- /k8s/delete_terminating_namespace.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -o errexit 4 | 5 | terminating_ns_array=`kubectl get namespaces | grep -o ".* Terminating" | awk '{print $1}'` 6 | 7 | terminating_ns_array=`echo ${terminating_ns_array} | sed 's/\n/ /g'` 8 | 9 | echo "Terminating namespaces: ${terminating_ns_array}" 10 | echo "" 11 | 12 | read -ra ns_array <<< "${terminating_ns_array}" 13 | 14 | temp_json_dir=/tmp/terminating_ns 15 | 16 | mkdir -p ${temp_json_dir} 17 | 18 | trap 'rm -rf ${temp_json_dir}' EXIT 19 | 20 | for (( i=0; i<${#ns_array[*]}; i++ )); do 21 | ns=${ns_array[$i]} 22 | kubectl get namespace ${ns} -o json > ${temp_json_dir}/${ns}.json 23 | sed -i '/^[ \t]*"kubernetes"$/d' ${temp_json_dir}/${ns}.json 24 | curl -s -H "Content-Type: application/json" -X PUT --data-binary @${temp_json_dir}/${ns}.json http://127.0.0.1:8080/api/v1/namespaces/${ns}/finalize > /dev/null 25 | echo "Namespace: ${ns} was finalized" 26 | done 27 | echo "" 28 | -------------------------------------------------------------------------------- /k8s/nvidia-docker.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [nvidia docker](#nvidia-docker) 6 | - [nvidia-docker 1.0 vs nvidia-docker 2.0](#nvidia-docker-10-vs-nvidia-docker-20) 7 | - [nvidia-docker 1.0](#nvidia-docker-10) 8 | - [nvidia-docker 2.0](#nvidia-docker-20) 9 | 10 | 11 | 12 | # nvidia docker 13 | 14 | ![](pics/nvidia-docker.png) 15 | 16 | ## nvidia-docker 1.0 vs nvidia-docker 2.0 17 | 18 | ### nvidia-docker 1.0 19 | 20 | ![](pics/nvidia-docker-v1.0.png) 21 | 22 | ### nvidia-docker 2.0 23 | 24 | ![](pics/nvidia-docker-v2.0.png) 25 | 26 | 上面已经介绍个各个组件的作用以及它们之间的关系，接下来详细的描述下这张图: 27 | 28 | 1.正常创建一个容器的流程是这样的: 29 | 30 | ``` 31 | docker --> dockerd --> docker-containerd-shm -->runc --> container-process 32 | ``` 33 | 34 | docker 客户端将创建容器的请求发送给 dockerd, 当 dockerd 收到请求任务之后将请求发送给 docker-containerd-shm (其实就是 containerd)。 35 | 36 | 创建 GPU 容器的流程如下: 37 | 38 | ``` 39 | docker--> dockerd --> docker-containerd-shim-->nvidia-container-runtime -- > container-process 40 | ``` 41 | 42 | 基本流程和不使用 GPU 的容器差不多，只是把 docker 默认的运行时替换成了 NVIDIA 自家的 nvidia-container-runtime。 43 | 44 | 这样当 nvidia-container-runtime 创建容器时，先执行 nvidia-container-runtime-hook 这个 hook 去检查容器是否需要使用 GPU (通过环境变量 NVIDIA_VISIBLE_DEVICES 来判断)。如果需要则调用 libnvidia-container 来暴露 GPU 给容器使用。否则走默认的 runc 逻辑。 45 | -------------------------------------------------------------------------------- /k8s/pics/RR模式.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/RR模式.png -------------------------------------------------------------------------------- /k8s/pics/cni_app.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/cni_app.png -------------------------------------------------------------------------------- /k8s/pics/cni_kubelet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/cni_kubelet.png -------------------------------------------------------------------------------- /k8s/pics/cni_plugin.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/cni_plugin.jpg -------------------------------------------------------------------------------- /k8s/pics/k8s_cni_plugin.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/k8s_cni_plugin.jpg -------------------------------------------------------------------------------- /k8s/pics/nvidia-docker-v1.0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/nvidia-docker-v1.0.png -------------------------------------------------------------------------------- /k8s/pics/nvidia-docker-v2.0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/nvidia-docker-v2.0.png -------------------------------------------------------------------------------- /k8s/pics/nvidia-docker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/nvidia-docker.png -------------------------------------------------------------------------------- /k8s/pics/package-api.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/k8s/pics/package-api.png -------------------------------------------------------------------------------- /k8s/require-for-storage.md: -------------------------------------------------------------------------------- 1 | # k8s 对存储的要求 2 | 3 | 1. 并发访问：多个副本相同的配置；大量并发读 4 | 2. 日志： 5 | 大量日志文件（可能是许多 rotate 的小文件），高吞吐量 6 | 如果需要分析日志，那么还要求大量并发读 7 | 3. 备份：k8s 集群备份，大容量、低成本、高吞吐 8 | 4. 分布式应用：Kafka、redis、es、hdfs，需要实时同步，低延时、高 iops 9 | -------------------------------------------------------------------------------- /micro-service/f3p-ManageLayer7Traffic.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/f3p-ManageLayer7Traffic.pdf -------------------------------------------------------------------------------- /micro-service/micro-service-stack.md: -------------------------------------------------------------------------------- 1 | # 一、微服务技术体系 2 | 3 | 下图列出了微服务的技术体系： 4 | 5 | ![5.jpeg](pics/5.jpeg) 6 | 7 | # 二、Golang微服务技术栈 8 | 9 | ## 微服务框架 10 | 11 | - go-micro 12 | - go-kit 13 | 14 | 国内的bilibili和斗鱼也出了一个微服务框架： 15 | 16 | - kratos bilibili出品 17 | - jupiter 斗鱼出品 18 | 19 | ## 网关 20 | 21 | - kong 22 | - nginx +lua 23 | - traefik 24 | - apisix 25 | 26 | ## 服务注册和发现 27 | 28 | - consul 29 | - etcd 30 | - zookeeper 31 | - nacos 32 | 33 | ## 配置中心 34 | 35 | - apollo 36 | - nacos 37 | 38 | ## 服务治理 39 | 40 | - 断路器：hystrix-go 41 | - 流量控制：sentinel-golang 从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性 42 | 43 | ## 链路监控 44 | 45 | - zipkin 46 | - pinpoint 47 | - skywalking 48 | - jaeger 49 | 50 | ## 日志、业务、系统监控 51 | 52 | - prometheus 53 | - ELK 54 | 55 | # 三、java微服务技术栈 56 | 57 | 用java技术开发微服务，比较主流的选择有：Spring Cloud 和 Dubbo。 58 | 59 | ## Spring Cloud 60 | 61 | Spring Cloud 是在Spring基础上构建的，它后面有2大公司支撑，Pivotal和Netfix的技术支持。它的核心就是Netflix贡献的源码，也是这家公司构建了整套微服务体系，才使得微服务架构逐渐流行开来，所以说Netflix在微服务上的贡献是巨大的。 62 | 63 | ### Pivotal的SpingCloud 64 | 65 | Pivotal的SpingCloud框架，`Spring Cloud`，这个是Pivotal集成了Netfix，或者重新改写了它的框架。 66 | 67 | Spring是一个全家桶，Spring Cloud也是一个全家桶，它由很多技术框架组合而成： 68 | 69 | - 服务治理服务注册和发现：Netflix Eureka 70 | 当然我们也有其他的选择，比如consul，etcd，zookeeper等 71 | - 断路器：Hystrix 72 | - 调用端负载均衡：RibbonREST 73 | - 网关：Zuul 74 | 当然我们也可以选择其他的，比如Spring Cloud Gateway，kong，nginx+lua，apisix等 75 | - 分布式链路监控: Spring Cloud Sleuth 76 | 埋点和发送数据当然还有其他的比如zipkin，pinpoint，skywalking，jaeger等 77 | - 消息组件: Spring Cloud StreamSpirng Cloud Bus 78 | - 消息中间件的其他软件：RocketMQ，Kafka，RabbitMQ 79 | - 配置中心: Spring Cloud Config，配置中心可以有其他的替代，比如Apollo，Nacos等 80 | - 安全控制: Spring Cloud Security 81 | 82 | ### 阿里巴巴的SpringCloud 83 | 84 | - Sentinel ：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性 85 | - Nacos ：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 86 | - RocketMQ ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。 87 | - Dubbo ：Apache Dubbo™ 是一款高性能 Java RPC 框架。 88 | - Seata ：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。 89 | - Alibaba Cloud ACM ：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。 90 | - Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。 91 | - Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。 92 | - Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。 93 | 94 | ### 阿里巴巴 dubbo 95 | 96 | 从上面spring-cloud-alibabba组件组成来看，Dubbo是它的一个子框架。 97 | 98 | Dubbo具有调度、发现、监控、治理、服务发现等功能。 99 | 100 | - 优点 101 | - Dubbo 支持 RPC 调用，服务之间的调用性能会很好 102 | - 支持多种序列化协议，如 Hessian、HTTP、WebService。 103 | - Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。 104 | - 在国内影响力比较大，中文社区文档较为全面。 105 | - 缺点 106 | - 它只是微服务的一个子集，一个子框架。服务治理 107 | - 国内公司用的多，阿里以前不维护，现在重启维护，而且还捐献给了apache基金会 108 | 109 | ### Dubbo和Spring Cloud对比 110 | 111 | ![6.jpeg](pics/6.jpeg) 112 | 113 | Dubbo是专注于RPC和服务治理，Spring Cloud是一个微服务的全家桶，也可以说是微服务生态，功能齐全，社区维护也积极。 114 | 115 | SpringCloud国内外公司应用多，dubbo主要是国内公司用的多。 116 | 117 | ## java微服务框架总结 118 | 119 | 就微服务体系来说，Dubbo只是整个微服务的一部分。Spring Cloud是一整套微服务体系，它是一个完整的解决方案。Spring Cloud社区强大，也很活跃。 120 | -------------------------------------------------------------------------------- /micro-service/pics/1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/pics/1.png -------------------------------------------------------------------------------- /micro-service/pics/2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/pics/2.png -------------------------------------------------------------------------------- /micro-service/pics/3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/pics/3.png -------------------------------------------------------------------------------- /micro-service/pics/4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/pics/4.png -------------------------------------------------------------------------------- /micro-service/pics/5.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/pics/5.jpeg -------------------------------------------------------------------------------- /micro-service/pics/6.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/micro-service/pics/6.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/availability.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/availability.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/ms1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/ms1.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/ms2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/ms2.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/ms3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/ms3.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/ms4.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/ms4.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha1.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha10.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha10.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha11.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha11.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha12.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha12.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha13.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha13.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha14.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha14.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha15.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha15.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha2.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha3.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha4.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha4.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha5.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha5.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha6.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha6.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha7.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha7.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha8.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha8.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/msha9.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/msha9.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/s1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/s1.jpeg -------------------------------------------------------------------------------- /multi-site-ha/pics/s2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/multi-site-ha/pics/s2.jpeg -------------------------------------------------------------------------------- /openstack/neutron/ip_types.md: -------------------------------------------------------------------------------- 1 | # 公有云 ip 概念 2 | 3 | 阿里云弹性公网IP使用更灵活，EIP可以独立持有，可以将EIP绑定到ECS、NAT网关、ENI网卡、私网负载均衡SLB上，也可以实现动态解绑，使用更灵活。固定公网IP是跟随ECS云服务器创建的，不可以解绑，也不可以绑定其他实例，固定IP可以转成EIP。 4 | 5 | 另外，公网IP可以在ECS实例的网卡上看到， 而EIP是通过NAT方式将IP地址映射到ECS的位于私网的网卡上，所以在网卡上看不到EIP。 6 | 7 | | 云产品 | 功能 | 优势 | 8 | | :--- | :--- | :--- | 9 | | ECS固定公网IP | 创建ECS时，为ECS选择分配公网IP地址，系统会自动分配一个支持公网访问的固定IP地址。固定公网IP是跟随ECS云服务器创建的，不可以解绑，也不可以绑定其他实例。| 支持使用共享流量包，将公网IP转换为EIP后也可以使用共享带宽。 固定公网IP可以在ECS实例的网卡上可以看到。| 10 | | 弹性公网IP（EIP） | EIP可以动态和VPC ECS实例绑定和解绑，支持VPC ECS实例访问公网（SNAT）和被公网访问（DNAT）。EIP可以绑定ECS、还能够绑定私网SLB和NAT网关 | EIP可以随时和ECS实例绑定和解绑。可以使用共享带宽和共享流量包，降低公网成本。EIP是通过NAT方式将IP地址映射到ECS的位于私网的网卡上，所以在ECS网卡上看不到EIP。 | 11 | | NAT网关 | 支持多台VPC ECS实例访问公网（SNAT）和被公网访问（DNAT）。说明：和负载均衡相比，NAT网关本身没有均衡流量的功能。 | NAT网关和EIP的核心区别是NAT网关可用于多台VPC ECS实例和公网通信，而EIP只能用于一台VPC ECS实例和公网通信。 | 12 | | 负载均衡SLB | 基于端口提供四层和七层负载均衡功能，支持用户从公网通过负载均衡（SLB）访问ECS。说明：负载均衡不支持VPC网络的ECS通过负载均衡主动访问公网（SNAT）。 | 在DNAT方面，负载均衡是基于端口的负载均衡，即一个负载均衡的一个端口可以对应多台ECS。负载均衡通过对多台ECS进行流量分发，可以扩展应用系统对外的服务能力，并通过消除单点故障提升应用系统的可用性。绑定EIP后，支持使用共享带宽和共享流量包，降低公网成本。 | 13 | 14 | 综上，阿里云专有网络VPC连接公网的方式中ECS固定公网IP、弹性公网IP（EIP）和负载均衡均支持共享带宽和共享流量包，有利于降低公网成本；弹性公网EIP相对于固定公网IP使用更加灵活。 15 | 16 | ![ip_types](pics/ip_types.jpeg) 17 | 18 | 另外，负载均衡SLB仅提供被动访问公网的能力，即后端ECS只能在收到经过负载均衡SLB转发来的公网的请求时，才能访问公网回应该请求，如后端ECS但愿主动发起公网访问，则须要配置/购买ECS公网带宽、弹性公网IP或NAT网关来实现。 19 | 20 | # Floating IP 21 | 22 | FIP 是 openstack 上的一个概念。浮动IP与弹性公网IP功能类似，都是公网IP，用于连接公网，主要不同点在于浮动IP接口无法配置带宽参数。 23 | -------------------------------------------------------------------------------- /openstack/neutron/pics/conntrack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/conntrack.png -------------------------------------------------------------------------------- /openstack/neutron/pics/conntrack2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/conntrack2.png -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr.png -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_case1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_case1.png -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_case2a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_case2a.png -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_case2b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_case2b.png -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_case3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_case3.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_ew.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_ew.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_ha.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_ha.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/dvr_sn.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/dvr_sn.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/flow_of_components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/flow_of_components.png -------------------------------------------------------------------------------- /openstack/neutron/pics/haproxy_ap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/haproxy_ap.png -------------------------------------------------------------------------------- /openstack/neutron/pics/ip_types.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/ip_types.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/lbaas_logic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/lbaas_logic.png -------------------------------------------------------------------------------- /openstack/neutron/pics/lbaas_service_architecture.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/lbaas_service_architecture.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/lbaasv2_concepts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/lbaasv2_concepts.png -------------------------------------------------------------------------------- /openstack/neutron/pics/netfilter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/netfilter.png -------------------------------------------------------------------------------- /openstack/neutron/pics/neutron_ha.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/neutron_ha.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/neutron_network_domains.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/neutron_network_domains.png -------------------------------------------------------------------------------- /openstack/neutron/pics/router.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/router.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/router_legacy.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/router_legacy.jpeg -------------------------------------------------------------------------------- /openstack/neutron/pics/router_legacy_ha.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/openstack/neutron/pics/router_legacy_ha.jpeg -------------------------------------------------------------------------------- /others/Software_Engineering_Advice_from_Building_Large-Scale_Distributed_Systems.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/others/Software_Engineering_Advice_from_Building_Large-Scale_Distributed_Systems.pdf -------------------------------------------------------------------------------- /others/dean-keynote-ladis2009-scalable-distributed-google.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/others/dean-keynote-ladis2009-scalable-distributed-google.pdf -------------------------------------------------------------------------------- /others/dual-stack-base.md: -------------------------------------------------------------------------------- 1 | # 双栈技术 2 | 3 | 双栈技术是IPv4向IPv6过渡的一种有效的技术。网络中的节点同时支持IPv4和IPv6协议栈，源节点根据目的节点的不同选用不同的协议栈，而网络设备根据报文的协议类型选择不同的协议栈进行处理和转发。双栈可以在一个单一的设备上实现，也可以是一个双栈骨干网。对于双栈骨干网，其中的所有设备必须同时支持IPv4/IPv6协议栈，连接双栈网络的接口必须同时配置IPv4地址和IPv6地址。单协议栈和双协议栈结构示例如图1所示。 4 | 5 | ![dual-stack](pics/dual-stack.png) 6 | 7 | 另一个视角如下： 8 | 9 | ![dual](pics/dual.gif) 10 | 11 | **双协议栈具有以下特点**： 12 | - 多种链路协议支持双协议栈 13 | 多种链路协议（如以太网）支持双协议栈。图中的链路层是以太网，在以太网帧上，如果协议ID字段的值为0x0800，表示网络层收到的是IPv4报文，如果为0x86DD，表示网络层是IPv6报文。 14 | - 多种应用支持双协议栈 15 | 多种应用（如DNS/FTP/Telnet等）支持双协议栈。上层应用（如DNS）可以选用TCP或UDP作为传输层的协议，但优先选择IPv6协议栈，而不是IPv4协议栈作为网络层协议。 16 | 17 | 如图2为双协议栈的一个典型应用： 18 | 19 | ![example](pics/example.png) 20 | 21 | 如图所示，主机向DNS服务器发送DNS请求报文，请求域名www.example.com对应的IP地址。DNS服务器将回复该域名对应的IP地址。如图所示，该IP地址可能是10.1.1.1或fc00::1。主机系统发送A类查询，则向DNS服务器请求对应的IPv4地址；系统发送AAAA查询，则向DNS服务器请求对应的IPv6地址。 22 | 23 | 图中Router支持双协议栈功能。如果主机访问IPv4地址为10.1.1.1的网络服务器，则可以通过Router的IPv4协议栈访问目标节点。如果主机访问IPv6地址为fc00::1的网络服务器，则可以通过Router的IPv6协议栈访问目标节点。 24 | 25 | 26 | -------------------------------------------------------------------------------- /others/high-throughput-metrics.md: -------------------------------------------------------------------------------- 1 | # 一文搞懂高并发性能指标：QPS、TPS、RT、并发数、吞吐量 2 | 3 | ![high-throughput](pics/high-throughput.jpeg) 4 | 5 | ## QPS，每秒查询 6 | 7 | QPS：Queries Per Second是衡量信息检索系统（例如搜索引擎或数据库）在一秒钟内接收到的搜索流量的一种常见度量。该术语在任何请求-响应系统中都得到更广泛的使用，更正确地称为每秒请求数（RPS：Request Per Second）。 8 | 9 | 高性能、高并发、高可用（简称“三高”）要求的系统必须注意其QPS，才能知道何时扩容系统以处理更多请求。 10 | 11 | **QPS 计算公式** 12 | 13 | ``` 14 | Queries Per Second Formula: 15 | 16 | QPS = Q/T/3600 17 | 18 | Variables: 19 | - QPS is the Queries Per Second (queries/sec) 20 | - Q is the number of queries 21 | - T is the total time (hours) 22 | ``` 23 | 24 | The following steps outline how to calculate the Queries Per Second. 25 | 26 | 1. First, determine the number of queries. 27 | 2. Next, determine the total time (hours). 28 | 3. Next, gather the formula from above = QPS = Q / T /3600. 29 | 30 | ## TPS，每秒事务 31 | 32 | TPS：是Transactions Per Second的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户端向服务器发送请求然后服务器做出响应的过程。客户端在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 33 | 34 | QPS vs TPS：QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。 35 | 36 | ## RT，响应时间 37 | 38 | RT（Response-time）响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间，即从客户端发起请求到收到服务器响应结果的时间。该请求可以是任何东西，从内存获取，磁盘IO，复杂的数据库查询或加载完整的网页。 39 | 40 | 暂时忽略传输时间，响应时间是处理时间和等待时间的总和。处理时间是完成请求要求的工作所需的时间，等待时间是请求在被处理之前必须在队列中等待的时间。 41 | 42 | 响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。 43 | 44 | ## Concurrency，并发数 45 | 46 | 并发数是指系统同时能处理的请求数量，这个也反应了系统的负载能力。 47 | 48 | 并发意味着可以同时进行多个处理。并发在现代编程中无处不在，网络中有多台计算机同时存在，一台计算机上同时运行着多个应用程序。 49 | 50 | ## 吞吐量 51 | 52 | 系统的吞吐量（承压能力）和处理对CPU的消耗、外部接口、IO等因素紧密关联。单个处理请求对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。 53 | 54 | 系统吞吐量有几个重要指标参数：QPS（TPS）、并发数、响应时间。 55 | 56 | QPS（TPS）：（Queries Per Second）每秒钟请求/事务数量。 57 | 并发数： 系统同时处理的请求/事务数。 58 | 响应时间： 一般取平均响应时间。 59 | 理解了上面三个指标的意义之后，就能推算出它们之间的关系： 60 | 61 | - **QPS（TPS）= 并发数/平均响应时间** 62 | - **并发数 = QPS*平均响应时间** 63 | 64 | ## 实际举例 65 | 66 | 我们通过一个实例来把上面几个概念串起来理解。按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 的时间就叫做峰值时间。 67 | 68 | - 公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 69 | - 机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 70 | 71 | 1. **每天300w PV 的在单台机器上，这台机器需要多少QPS？** 72 | ( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS) 73 | 2. **如果一台机器的QPS是58，需要几台机器来支持？** 74 | 139 / 58 = 3 75 | 76 | ## 最佳线程数、QPS、RT 77 | 78 | 1. **单线程QPS公式：QPS=1000ms/RT** 79 | 对同一个系统而言，支持的线程数越多，QPS越高。假设一个RT是80ms，则可以很容易的计算出QPS，QPS = 1000/80 = 12.5。 80 | 81 | 多线程场景，如果把服务端的线程数提升到2，那么整个系统的QPS则为 2*（1000/80） = 25，可见QPS随着线程的增加而线性增长，那QPS上不去就加线程呗，听起来是这个道理，但是往往现实并非如此。 82 | 83 | 2. 最佳线程数量 84 | 85 | 刚好消耗完服务器的瓶颈资源的临界线程数，公式如下 86 | 最佳线程数量=（（线程等待时间+线程cpu时间）/ 线程cpu时间）* cpu数量 87 | 特性： 88 | 89 | 在达到最佳线程数的时候，线程数量继续递增，则QPS不变，而响应时间变长，持续递增线程数量，则QPS开始下降。 90 | 每个系统都有其最佳线程数量，但是不同状态下，最佳线程数量是会变化的。 91 | 瓶颈资源可以是CPU，可以是内存，可以是锁资源，IO资源，超过最佳线程数-->导致资源的竞争，超过最佳线程数-->响应时间递增。 92 | 93 | # References 94 | 95 | - 96 | - 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | -------------------------------------------------------------------------------- /others/numbers-everyone-should-know.md: -------------------------------------------------------------------------------- 1 | # Numbers Everyone Should Know 2 | 3 | | device | average access time | 4 | | :-----| :---- | 5 | | L1 cache reference 读取CPU的一级缓存 | 0.5 ns | 6 | | Branch mispredict (转移、分支预测) | 5 ns | 7 | | L2 cache reference 读取CPU的二级缓存 | 7 ns | 8 | | Mutex lock/unlock 互斥锁/解锁 | 100 ns | 9 | | Main memory reference 读取内存数据 | 100 ns | 10 | | Compress 1K bytes with Zippy 1K 字节压缩 | 10 us | 11 | | Send 2K bytes over 1 Gbps network 在 1Gbps 的网络上发送 2K 字节 | 20 us | 12 | | Read 1 MB sequentially from memory 从内存顺序读取 1MB | 250 us | 13 | | Round trip within same datacenter 从一个数据中心往返一次，ping 一下 | 500 us | 14 | | Disk seek 磁盘搜索 | 10 ms | 15 | | Read 1 MB sequentially from network 从网络上顺序读取 1M 的数据 | 10 ms | 16 | | Read 1 MB sequentially from disk 从磁盘里面读出 1MB | 30 ms | 17 | | Send packet CA->Netherlands->CA 一个包的一次远程访问 | 150 ms | 18 | 19 | Refers: 20 | - [Software Engineering Advice from 21 | Building Large-Scale Distributed Systems](Software_Engineering_Advice_from_Building_Large-Scale_Distributed_Systems.pdf) 22 | - [Jeff dean: keynote-ladis2009-scalable-distributed-google](dean-keynote-ladis2009-scalable-distributed-google.pdf) 23 | -------------------------------------------------------------------------------- /others/pics/dual-stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/others/pics/dual-stack.png -------------------------------------------------------------------------------- /others/pics/dual.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/others/pics/dual.gif -------------------------------------------------------------------------------- /others/pics/example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/others/pics/example.png -------------------------------------------------------------------------------- /others/pics/high-throughput.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/others/pics/high-throughput.jpeg -------------------------------------------------------------------------------- /others/yaml.md: -------------------------------------------------------------------------------- 1 | **Block styles with block chomping indicator (>-, |-, >+, |+)** 2 | 3 | You can control the handling of the final new line in the string, and any trailing blank lines (\n\n) by adding a block chomping indicator character: 4 | 5 | >, |: "clip": keep the line feed, remove the trailing blank lines. 6 | >-, |-: "strip": remove the line feed, remove the trailing blank lines. 7 | >+, |+: "keep": keep the line feed, keep trailing blank lines. 8 | -------------------------------------------------------------------------------- /spark/pics/client-mode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/spark/pics/client-mode.png -------------------------------------------------------------------------------- /spark/pics/cluster-mode-on-k8s.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/spark/pics/cluster-mode-on-k8s.png -------------------------------------------------------------------------------- /spark/pics/cluster-mode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/spark/pics/cluster-mode.png -------------------------------------------------------------------------------- /spark/pics/spark-operator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/spark/pics/spark-operator.png -------------------------------------------------------------------------------- /spark/pics/spark架构原理图.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/spark/pics/spark架构原理图.jpg -------------------------------------------------------------------------------- /terway/Terway-详解.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/Terway-详解.pdf -------------------------------------------------------------------------------- /terway/pics/aly_dns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/aly_dns.png -------------------------------------------------------------------------------- /terway/pics/cni_eni.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/cni_eni.png -------------------------------------------------------------------------------- /terway/pics/cni_eniip.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/cni_eniip.png -------------------------------------------------------------------------------- /terway/pics/cni_pod_create.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/cni_pod_create.png -------------------------------------------------------------------------------- /terway/pics/dns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/dns.png -------------------------------------------------------------------------------- /terway/pics/dns_speedup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/dns_speedup.png -------------------------------------------------------------------------------- /terway/pics/ebpf.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/ebpf.png -------------------------------------------------------------------------------- /terway/pics/ebpf_iptables.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/ebpf_iptables.png -------------------------------------------------------------------------------- /terway/pics/eni_eniip.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/eni_eniip.png -------------------------------------------------------------------------------- /terway/pics/eni_pool.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/eni_pool.png -------------------------------------------------------------------------------- /terway/pics/ip_batch_request.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/ip_batch_request.png -------------------------------------------------------------------------------- /terway/pics/iptables.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/iptables.png -------------------------------------------------------------------------------- /terway/pics/loadbalancer_service.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/loadbalancer_service.png -------------------------------------------------------------------------------- /terway/pics/node_local_dns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/node_local_dns.png -------------------------------------------------------------------------------- /terway/pics/overlay.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/overlay.png -------------------------------------------------------------------------------- /terway/pics/p_iptables.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/p_iptables.png -------------------------------------------------------------------------------- /terway/pics/performance1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/performance1.png -------------------------------------------------------------------------------- /terway/pics/performance2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/performance2.png -------------------------------------------------------------------------------- /terway/pics/pod_network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/pod_network.png -------------------------------------------------------------------------------- /terway/pics/resolv.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/resolv.png -------------------------------------------------------------------------------- /terway/pics/route.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/route.png -------------------------------------------------------------------------------- /terway/pics/service.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/service.png -------------------------------------------------------------------------------- /terway/pics/vpc_cni.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/vpc_cni.png -------------------------------------------------------------------------------- /terway/pics/vpc_network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/terway/pics/vpc_network.png -------------------------------------------------------------------------------- /volume/pv_pvc.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [PV/PVC](#pvpvc) 6 | - [PV and PVC share](#pv-and-pvc-share) 7 | 8 | 9 | 10 | # PV/PVC 11 | 12 | Three approaches to use cloud disk: 13 | 14 | - If you know the clear cloud disk id, just use it 15 | - PV/PVC mechanisam 16 | - Auto-provision PVC 17 | 18 | # PV and PVC share 19 | 20 | You can share pv and pvc within the same namespace for shared volumes (nfs, glusterfs, ...), you can also access your shared volume from multiple namespace, but it will require dedicated pv and pvs, as a pv is bound to a single namespace and pvc is namespace scoped. 21 | 22 | The pv is global that it can be seen by any namespace, but once it is bound to a namespace, it can then only be accessed by containers from the same namespace. 23 | 24 | The pvc is namespace scoped. If you have multiple namespaces you would need to have a new pv and pvc for each namespace to connect to the shared nfs volume, and you cann't reuse the pv in the first namespace. 25 | 26 | Example 1: 27 | Two distinct pods running the same namespace, both access the same pv and nfs exported share with the same pvc. 28 | 29 | Example 2: 30 | In namespace1, i have two pods share the same pv and the shared nfs volume with the same pvc. In namespace2, i would need another pv and pvc to share the nfs exported volume. 31 | 32 | Example 3: 33 | If bypassing pv and pvc, i can connect to the shared nfs volume directly from any namespace container by using the nfs plugin directly: 34 | 35 | ``` 36 | volume: 37 | - name: nfs-volume 38 | nfs: 39 | path: /xxxx/yyyy 40 | server: 192.168.1.10 41 | ``` 42 | 43 | Container's access mode seprated from pv/pvc's access mode. The later is for node, and the former is for container. We can mount a nfs volume with RW mode, but just let containter access the volume with RO mode when mapping the volume to container. 44 | -------------------------------------------------------------------------------- /volume/volume.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/keontang/work-notes/277354480ce802a4bd25faf14989a4a143475bcc/volume/volume.png -------------------------------------------------------------------------------- /wait/wait.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | **Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* 4 | 5 | - [package wait](#package-wait) 6 | - [Related files](#related-files) 7 | - [Forever](#forever) 8 | - [Until](#until) 9 | - [JitterUntil](#jitteruntil) 10 | - [Jitter](#jitter) 11 | 12 | 13 | 14 | # package wait 15 | 16 | ## Related files 17 | 18 | pkg/util/wait/wait.go 19 | 20 | ## Forever 21 | 22 | ``` 23 | // NeverStop may be passed to Until to make it never stop. 24 | var NeverStop <-chan struct{} = make(chan struct{}) 25 | 26 | // Forever is syntactic sugar on top of Until 27 | func Forever(f func(), period time.Duration) { 28 | Until(f, period, NeverStop) 29 | } 30 | ``` 31 | 32 | Forever 周期性的执行 f 函数，永远不会停止。因为 NeverStop channel 不用来发送接收数据，只用来控制循环，如果我们不关闭 NeverStop channel，Forever 函数就会一直循环执行下去。为什么呢？下面我们看看 Until 函数。 33 | 34 | ## Until 35 | 36 | ``` 37 | // Until loops until stop channel is closed, running f every period. 38 | // Until is syntactic sugar on top of JitterUntil with zero jitter factor 39 | func Until(f func(), period time.Duration, stopCh <-chan struct{}) { 40 | JitterUntil(f, period, 0.0, stopCh) 41 | } 42 | ``` 43 | 44 | Until 函数的功能是：周期性的执行 f 函数，除非 stopCh channel 被关闭。下面看看 JitterUntil 函数。 45 | 46 | ## JitterUntil 47 | 48 | ``` 49 | // JitterUntil loops until stop channel is closed, running f every period. 50 | // If jitterFactor is positive, the period is jittered before every run of f. 51 | // If jitterFactor is not positive, the period is unchanged. 52 | // Catches any panics, and keeps going. f may not be invoked if 53 | // stop channel is already closed. Pass NeverStop to Until if you 54 | // don't want it stop. 55 | func JitterUntil(f func(), period time.Duration, jitterFactor float64, stopCh <-chan struct{}) { 56 | /* 57 | * golang 中的 select 和 switch 是容易混淆的两个关键字，因为他们都带 case 语句。 58 | * 注意到 select 的代码形式和 switch 非常相似， 不过 select 的 case 里的操作语句只能是 IO 操作。 59 | * 即，golang 的 select 的功能和 select/poll/epoll 相似， 就是监听 IO 操作，当 IO 操作发生时，触发相应的动作。 60 | * 当 select 只有 case 语句的时候，case 不满足的话，是一直要阻塞的 61 | * 但是当 default 语句存在时，如果 case 语句不满足，则直接执行 default 语句而不阻塞。 62 | */ 63 | select { 64 | case <-stopCh: 65 | return 66 | default: 67 | } 68 | 69 | /* 周期性执行 f 函数，除非 stopCh channel 已关闭 */ 70 | for { 71 | func() { 72 | defer runtime.HandleCrash() 73 | f() 74 | }() 75 | 76 | jitteredPeriod := period 77 | /* 78 | * 如果 jitterFactor 为正数，则返回一个抖动周期值：period * (1 + 0.x * jitterFactor) 79 | * 其中 0.x 为 [0.0 1.0) 的随机值 80 | * 81 | * 如果 jitterFactor 为负数或者0.0，则周期保持不变 82 | * 83 | * 其实，引入抖动周期的目的是避免所有 clients 的周期性行为出现收敛 84 | * 比如，避免所有 clients 都在 0.1 秒后都需要执行各自的 f 函数 85 | */ 86 | if jitterFactor > 0.0 { 87 | jitteredPeriod = Jitter(period, jitterFactor) 88 | } 89 | 90 | select { 91 | case <-stopCh: 92 | return 93 | case <-time.After(jitteredPeriod): 94 | } 95 | } 96 | } 97 | ``` 98 | 99 | jitter 是什么呢？所谓 jitter 就是一种抖动。具体如何解释呢？其定义延迟从来源地址将要发送到目标地址，会发生不一样的延迟，这样的延迟变动是jitter让我们来看一个例子。假如你有个女友，你希望她每天晚上下班之后7点来找你，而有的时候她6:30到，有的时候是7:23，有的时候也许是下一天。这种时间上的不稳定就是jitter。如果你多观察这种时间上的不规律性，你会对 jitter 有更深一些的理解。在你观察的这段期间内，女友最早和最晚到来的时间被称为“jitter全振幅”（peak to peak jitter amplitude)。“jitter半振幅”（jitter-amplitude）就是你女友实际来的时间和7点之间的差值。女友来的时间有早有晚，jitter 半振幅也有正有负。通过计算，你可以找出 jitter 半振幅的平均值，如果你能够计算出你女友最有可能在哪个时间来，你就可以发现女友来的时间是完全无规律的（随机 jitter random jitter）还是和某些特定事情有关系（关联 jitter correlated jitter）。所谓关联 jitter 就是比如你知道你的女友周四要晚来，因为她要去看她的妈妈。如果你能彻底明白这点，你就已经是一个 correlated jitter 的专家了。 100 | 101 | ## Jitter 102 | 103 | ``` 104 | // Jitter returns a time.Duration between duration and duration + maxFactor * duration, 105 | // to allow clients to avoid converging on periodic behavior. If maxFactor is 0.0, a 106 | // suggested default value will be chosen. 107 | func Jitter(duration time.Duration, maxFactor float64) time.Duration { 108 | if maxFactor <= 0.0 { 109 | maxFactor = 1.0 110 | } 111 | /* Float64 returns, as a float64, a pseudo-random number in [0.0,1.0) from the default Source. */ 112 | wait := duration + time.Duration(rand.Float64()*maxFactor*float64(duration)) 113 | return wait 114 | } 115 | ``` 116 | 117 | 118 | -------------------------------------------------------------------------------- /开发环境构建/Dockerfile: -------------------------------------------------------------------------------- 1 | # 基础镜像 2 | FROM ubuntu:latest 3 | # 修改国内源 4 | RUN sed -i 's/archive.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list 5 | RUN sed -i 's/security.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list 6 | # 执行命令 7 | # 安装 python3、openai、streamlit、golang 8 | RUN apt-get update \ 9 | && apt-get install gcc libc6-dev git lrzsz -y \ 10 | && apt-get install python3 python3-dev python3-pip -y \ 11 | && pip install openai streamlit poe-api \ 12 | && apt-get install golang -y \ 13 | && apt-get clean \ 14 | && rm -rf /tmp/* /var/lib/apt/lists/* /var/tmp/* 15 | # 建立软链接 16 | RUN ln -s /usr/bin/python3 /usr/bin/python 17 | # 配置环境变量 18 | ENV GOROOT=/usr/lib/go 19 | ENV PATH=$PATH:/usr/lib/go/bin 20 | ENV GOPATH=/root/go 21 | ENV PATH=$GOPATH/bin/:$PATH 22 | # 定制工作目录 23 | RUN mkdir -p /root/go/src/github.com/keontang/ 24 | WORKDIR /root/go/src/github.com/keontang/ 25 | 26 | EXPOSE 80 27 | EXPOSE 8080 28 | EXPOSE 8501 29 | 30 | ENTRYPOINT ["/bin/bash"] 31 | -------------------------------------------------------------------------------- /开发环境构建/dev.dockerfile: -------------------------------------------------------------------------------- 1 | # 基础镜像 2 | FROM ubuntu:latest 3 | # 修改国内源 4 | RUN sed -i 's/archive.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list 5 | RUN sed -i 's/security.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list 6 | # 执行命令 7 | # 安装 python3、openai、streamlit、golang 8 | RUN apt-get update \ 9 | && apt-get install gcc libc6-dev git lrzsz -y \ 10 | && apt-get install python3 python3-dev python3-pip -y \ 11 | && apt-get install wget vim curl unzip -y \ 12 | && apt-get clean \ 13 | && rm -rf /tmp/* /var/lib/apt/lists/* /var/tmp/* 14 | # 建立软链接 15 | RUN ln -s /usr/bin/python3 /usr/bin/python 16 | # install golang 17 | RUN wget https://go.dev/dl/go1.20.1.linux-amd64.tar.gz \ 18 | && tar -C /usr/local -xzf go1.20.1.linux-amd64.tar.gz \ 19 | && rm go1.20.1.linux-amd64.tar.gz 20 | # 配置环境变量 21 | ENV GOROOT=/usr/local/go 22 | ENV PATH=$PATH:/usr/local/go/bin 23 | ENV GOPATH=/root/go 24 | ENV PATH=$PATH:$GOPATH/bin/ 25 | # 定制工作目录 26 | RUN mkdir -p /root/go/src \ 27 | && mkdir -p /root/go/bin \ 28 | && mkdir -p /root/go/keontang 29 | WORKDIR /root/go/keontang/ 30 | 31 | # 安装 hertz 32 | RUN go install github.com/cloudwego/hertz/cmd/hz@latest 33 | # 安装 kitex 34 | RUN go install github.com/cloudwego/kitex/tool/cmd/kitex@latest \ 35 | && go install github.com/cloudwego/thriftgo@latest 36 | # 安装 protocol 编译器 37 | RUN PROTOC_VERSION=$(curl -s \ 38 | "https://api.github.com/repos/protocolbuffers/protobuf/releases/latest" \ 39 | | grep -Po '"tag_name": "v\K[0-9.]+') \ 40 | && curl -Lo protoc.zip \ 41 | "https://github.com/protocolbuffers/protobuf/releases/latest/download/protoc-${PROTOC_VERSION}-linux-x86_64.zip" \ 42 | && unzip protoc.zip -d /usr/local \ 43 | && chmod a+x /usr/local/bin/protoc \ 44 | && rm -rf protoc.zip 45 | # 安装 protocol golang 插件：protoc-gen-go 46 | RUN go install github.com/golang/protobuf/protoc-gen-go@latest 47 | # 安装 golangci-lint; refer to: https://golangci-lint.run/usage/install/ 48 | RUN curl -sSfL \ 49 | https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh \ 50 | | sh -s -- -b /root/go/bin v1.53.3 51 | 52 | EXPOSE 80 53 | EXPOSE 8080 54 | 55 | ENTRYPOINT ["/bin/bash"] 56 | --------------------------------------------------------------------------------